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: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] staging: vme_user: validate slave window size against buffer size
Date: Thu, 21 May 2026 11:20:14 +0200	[thread overview]
Message-ID: <2026052104-venture-batboy-54d2@gregkh> (raw)
In-Reply-To: <20260514034511.4244-1-kiguchi.r.sec@gmail.com>

On Thu, May 14, 2026 at 12:45:10PM +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.
> 
> Additionally, a slave.size of 0 is permitted, which causes vme_get_size()
> to return 0. In vme_user_read() and vme_user_write(), the boundary check
> (*ppos > image_size - 1) suffers from an integer underflow because
> image_size is size_t. This bypasses the bounds check entirely, allowing
> offsets 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 == 0 and slave.size > size_buf in the VME_SET_SLAVE
> handler. With this check in place, the existing bounds checks in
> vme_user_read() / vme_user_write() against vme_get_size() are
> sufficient to prevent OOB access.
> 
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Rion Kiguchi <kiguchi.r.sec@gmail.com>
> ---
> Changes in v4:
>  - Add check for slave.size == 0 to prevent integer underflow in bounds check.
>  - Remove trailing whitespaces inadvertently added in previous versions.
>  - Remove Fixes and Cc: stable tags to resolve checkpatch warnings based on maintainer feedback.

Please see the review comments:
	https://sashiko.dev/#/patchset/20260514034511.4244-1-kiguchi.r.sec@gmail.com



      reply	other threads:[~2026-05-21  9:20 UTC|newest]

Thread overview: 9+ 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
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
2026-05-21  9:20         ` Greg KH [this message]

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=2026052104-venture-batboy-54d2@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=kiguchi.r.sec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    /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.