All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Rion Kiguchi <kiguchi.r.sec@gmail.com>
Cc: stable@vger.kernel.org
Subject: Re: [PATCH] staging: vme_user: validate slave window size against buffer size
Date: Sat, 9 May 2026 10:04:04 +0200	[thread overview]
Message-ID: <2026050935-designing-glancing-2e16@gregkh> (raw)
In-Reply-To: <20260509075318.640383-1-kiguchi.r.sec@gmail.com>

On Sat, May 09, 2026 at 04:53:18PM +0900, Rion Kiguchi wrote:
> The VME_SET_SLAVE ioctl in drivers/staging/vme_user/vme_user.c accepts
> a user-controlled slave.size and forwards it to vme_slave_set() without
> comparing it against image[minor].size_buf. The slave-image kernel
> buffer is allocated at probe time with a fixed size of PCI_BUF_SIZE
> (0x20000 / 128 KiB), but the configured VME window size can be made
> much larger via the ioctl.
> 
> The subsequent read() / write() handlers (vme_user_read /
> vme_user_write) clamp the I/O range against vme_get_size() (the
> configured window size, attacker-controlled) but never consult
> size_buf. The slave I/O paths buffer_to_user() and buffer_from_user()
> then index image[minor].kern_buf with *ppos values up to
> image_size - 1, well beyond the actual allocation.
> 
> Result: a local user with read/write access to /dev/bus/vme/s* can
> trigger out-of-bounds read and write of the kernel slab adjacent to
> the slave-image buffer.
> 
> Fix: reject slave.size > size_buf in the VME_SET_SLAVE handler. Also
> add defensive bounds checks against size_buf in buffer_to_user() and
> buffer_from_user() so that the I/O paths cannot exceed the
> allocation even if a future ioctl path forgets to validate.
> 
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Rion Kiguchi <kiguchi.r.sec@gmail.com>
> ---
>  drivers/staging/vme_user/vme_user.c | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/vme_user/vme_user.c b/drivers/staging/vme_user/vme_user.c
> index 11e25c2f6..41b8d5b51 100644
> --- a/drivers/staging/vme_user/vme_user.c
> +++ b/drivers/staging/vme_user/vme_user.c
> @@ -156,6 +156,11 @@ static ssize_t buffer_to_user(unsigned int minor, char __user *buf,
>  {
>  	void *image_ptr;
>  
> +	if (*ppos < 0 || (u64)*ppos >= image[minor].size_buf ||
> +	    count > image[minor].size_buf - (u64)*ppos) {
> +		pr_warn_ratelimited("%s: out-of-bounds access\n", __func__);
> +		return -EINVAL;
> +	}

Why doesn't the check in vme_user_read() already catch this?  You are
duplicating much of the same logic again, are you _SURE_ the
LLM-generated report here is actually correct?

And don't spam the kernel log for when a user sends invalid data, that
would just be a mess.  But if you do want to, use the proper device
information, not just a static function name, which is very generic and
impossible to determine what went wrong (i.e. use the correct logging
functions like dev_err() and the like).

And you need an extra blank line after the check here, your LLM should
know better :)

>  	image_ptr = image[minor].kern_buf + *ppos;
>  	if (copy_to_user(buf, image_ptr, (unsigned long)count))
>  		return -EFAULT;
> @@ -168,6 +173,11 @@ static ssize_t buffer_from_user(unsigned int minor, const char __user *buf,
>  {
>  	void *image_ptr;
>  
> +	if (*ppos < 0 || (u64)*ppos >= image[minor].size_buf ||
> +	    count > image[minor].size_buf - (u64)*ppos) {
> +		pr_warn_ratelimited("%s: out-of-bounds access\n", __func__);
> +		return -EINVAL;
> +	}

Same as above.

thanks,

greg k-h

  reply	other threads:[~2026-05-09  8:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-09  7:53 [PATCH] staging: vme_user: validate slave window size against buffer size Rion Kiguchi
2026-05-09  8:04 ` Greg KH [this message]
2026-05-09  9:07   ` [PATCH v3] " Rion Kiguchi
2026-05-09  9:15     ` Greg KH
2026-05-09  9:16     ` Greg KH
2026-05-09  9:26   ` Rion Kiguchi
2026-05-09  9:58     ` Greg Kroah-Hartman
2026-05-14  3:45       ` [PATCH v4] " Rion Kiguchi
  -- strict thread matches above, loose matches on Subject: below --
2026-05-09  8:02 [PATCH] " Rion Kiguchi
2026-05-09  6:58 木口璃音
2026-05-09  7:15 ` gregkh
2026-05-09  7:17 ` gregkh

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=2026050935-designing-glancing-2e16@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=kiguchi.r.sec@gmail.com \
    --cc=stable@vger.kernel.org \
    /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.