All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: soufianeda@tutanota.com
Cc: sakari.ailus@linux.intel.com, linux-staging@lists.linux.dev
Subject: Re: [PATCH] staging: atomisp: fix heap buffer overflow in framebuffer conversion
Date: Tue, 10 Feb 2026 21:53:50 +0300	[thread overview]
Message-ID: <aYt-vrc7h7CJOmSu@stanley.mountain> (raw)
In-Reply-To: <20260210-atomisp-fix-v1-1-024429cbff31@tutanota.com>

On Tue, Feb 10, 2026 at 04:26:31PM +0100, Soufiane via B4 Relay wrote:
> From: Soufiane <soufianeda@tutanota.com>
> 
> Validate sizeimage against the allocated frame buffer size before
> hmm_store() to prevent out-of-bounds write.
> 
> Signed-off-by: Soufiane <soufianeda@tutanota.com>

We need a Fixes tag if the bug is real.

> ---
>  drivers/staging/media/atomisp/pci/atomisp_cmd.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
> index 3a4eb4f6d3be..ca7ffc7855ac 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
> @@ -3326,6 +3326,11 @@ atomisp_v4l2_framebuffer_to_css_frame(const struct v4l2_framebuffer *arg,
>  		goto err;
>  	}
>  

There is some sketchy stuff happening in this code but I'm not sure I
understand the issue.  The code looks like this:

  3317          /* Note: the padded width on an ia_css_frame is in elements, not in
  3318             bytes. The RAW frame we use here should always be a 16bit RAW
  3319             frame. This is why we bytesperline/2 is equal to the padded with */
  3320          if (ia_css_frame_allocate(&res, arg->fmt.width, arg->fmt.height,
  3321                                         sh_format, padded_width, 0)) {

This allocates res.  Why would it allocate something smaller than
arg->fmt.sizeimage?  How did you find this bug?  By testing or reading
the code?  Do you have a reproducer?

  3322                  ret = -ENOMEM;
  3323                  goto err;
  3324          }

> +	if (arg->fmt.sizeimage > res->data_bytes) {
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +

  3325  
  3326          tmp_buf = vmalloc(arg->fmt.sizeimage);
  3327          if (!tmp_buf) {
  3328                  ret = -ENOMEM;
  3329                  goto err;
  3330          }
  3331          if (copy_from_user(tmp_buf, (void __user __force *)arg->base,
  3332                             arg->fmt.sizeimage)) {
  3333                  ret = -EFAULT;
  3334                  goto err;
  3335          }
  3336  
  3337          if (hmm_store(res->data, tmp_buf, arg->fmt.sizeimage)) {
                              ^^^^^^^^^
The worry is that the buffer this references is too small.  I would
prefer instead if there were some bounds checking before the memcpy()
calls in hmm_store().  They would use a different, smaller limit if
only part of the buffer could be used.  I don't know if that bounds
checking is really required though...

  3338                  ret = -EINVAL;
  3339                  goto err;
  3340          }
  3341  

regards,
dan carpenter


  parent reply	other threads:[~2026-02-10 19:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-10 15:26 [PATCH] staging: atomisp: fix heap buffer overflow in framebuffer conversion Soufiane
2026-02-10 15:26 ` Soufiane via B4 Relay
2026-02-10 15:40 ` Greg KH
2026-02-10 18:53 ` Dan Carpenter [this message]
2026-02-11  8:11   ` Sakari Ailus
2026-02-11  8:59     ` Andy Shevchenko
2026-02-11 11:28     ` johannes.goede
2026-02-11 11:39       ` Andy Shevchenko
2026-02-11 11:50         ` johannes.goede
2026-02-11 11:54           ` Sakari Ailus
2026-02-11 12:31             ` johannes.goede
2026-02-11 13:27               ` Andy Shevchenko
2026-02-11 13:43     ` soufianeda
2026-02-27 23:58       ` Sakari Ailus
     [not found]   ` <Ol83sWa--F-9@tutanota.com>
     [not found]     ` <aYwVNjC7Zbhr_4vo@stanley.mountain>
2026-02-11 13:37       ` soufianeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aYt-vrc7h7CJOmSu@stanley.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=sakari.ailus@linux.intel.com \
    --cc=soufianeda@tutanota.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.