Hi Jacopo,
Thank you for the patch.
On Tue, Aug 27, 2024 at 09:40:16AM +0200, Jacopo Mondi wrote:
> The config parameters buffer is already validated in
> pisp_be_validate_config() at .buf_prepare() time.
Unfortunately .buf_prepare() isn't the right place to handle the
validation. Userspace should not modify the contents of the buffer
before BUF_PREPARE and QBUF, but malicious (or just buggy) userspace
may. The validation should thus be moved to .buf_queue().
> However some of the same validations are also performed at
> pispbe_schedule() time. In particular the function checks that:
>
> 1) config.num_tiles is valid
> 2) At least one of the BAYER or RGB input is enabled
>
> The input validation is already performed in pisp_be_validate_config()
> and there is no need to repeat that at pispbe_schedule() time.
Is that the same validation though ? The one in
pisp_be_validate_config() validates config->config.global, while the
validation in pispbe_schedule() validates job.hw_enables. The latter is
set from config->config.global in pispbe_xlate_addrs(), but is later
modified in the function.
> The num_tiles validation can be moved to pisp_be_validate_config() as
> well. As num_tiles is a u32 it can'be be < 0, so change the sanity
> check accordingly.
>
> Signed-off-by: Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx>
> ---
> .../platform/raspberrypi/pisp_be/pisp_be.c | 25 ++++++-------------
> 1 file changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/platform/raspberrypi/pisp_be/pisp_be.c b/drivers/media/platform/raspberrypi/pisp_be/pisp_be.c
> index 8ba1b9f43ba1..73a5c88e25d0 100644
> --- a/drivers/media/platform/raspberrypi/pisp_be/pisp_be.c
> +++ b/drivers/media/platform/raspberrypi/pisp_be/pisp_be.c
> @@ -588,24 +588,6 @@ static void pispbe_schedule(struct pispbe_dev *pispbe, bool clear_hw_busy)
> pispbe->hw_busy = true;
> spin_unlock_irqrestore(&pispbe->hw_lock, flags);
>
> - if (job.config->num_tiles <= 0 ||
> - job.config->num_tiles > PISP_BACK_END_NUM_TILES ||
> - !((job.hw_enables.bayer_enables | job.hw_enables.rgb_enables) &
> - PISP_BE_BAYER_ENABLE_INPUT)) {
> - /*
> - * Bad job. We can't let it proceed as it could lock up
> - * the hardware, or worse!
> - *
> - * For now, just force num_tiles to 0, which causes the
> - * H/W to do something bizarre but survivable. It
> - * increments (started,done) counters by more than 1,
> - * but we seem to survive...
> - */
> - dev_dbg(pispbe->dev, "Bad job: invalid number of tiles: %u\n",
> - job.config->num_tiles);
> - job.config->num_tiles = 0;
> - }
> -
> pispbe_queue_job(pispbe, &job);
>
> return;
> @@ -703,6 +685,13 @@ static int pisp_be_validate_config(struct pispbe_dev *pispbe,
> return -EIO;
> }
>
> + if (config->num_tiles == 0 ||
> + config->num_tiles > PISP_BACK_END_NUM_TILES) {
> + dev_dbg(dev, "%s: Invalid number of tiles: %d\n", __func__,
> + config->num_tiles);
> + return -EIO;
Isn't -EINVAL a better error code ?
> + }
> +
> /* Ensure output config strides and buffer sizes match the V4L2 formats. */
> fmt = &pispbe->node[TDN_OUTPUT_NODE].format;
> if (bayer_enables & PISP_BE_BAYER_ENABLE_TDN_OUTPUT) {
--
Regards,
Laurent Pinchart
