All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rion Kiguchi <kiguchi.r.sec@gmail.com>
To: gregkh@linuxfoundation.org
Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
	Rion Kiguchi <kiguchi.r.sec@gmail.com>
Subject: [PATCH v4] staging: vme_user: validate slave window size against buffer size
Date: Thu, 14 May 2026 12:45:10 +0900	[thread overview]
Message-ID: <20260514034511.4244-1-kiguchi.r.sec@gmail.com> (raw)
In-Reply-To: <2026050947-easily-choosing-2f91@gregkh>

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.

Changes in v3:
 - Drop redundant checks in buffer_to_user() / buffer_from_user();
   the existing vme_get_size()-based bounds checks in vme_user_read()
   / vme_user_write() are sufficient once VME_SET_SLAVE rejects
   oversized windows.

Changes in v2:
 - Use git send-email instead of Gmail web compose.
 - Drop redundant Reported-by tag.
 - Add Assisted-by tag.

 drivers/staging/vme_user/vme_user.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/staging/vme_user/vme_user.c b/drivers/staging/vme_user/vme_user.c
index 11e25c2f6..ba4c9a6d0 100644
--- a/drivers/staging/vme_user/vme_user.c
+++ b/drivers/staging/vme_user/vme_user.c
@@ -394,6 +394,16 @@ static int vme_user_ioctl(struct inode *inode, struct file *file,
 				return -EFAULT;
 			}
 
+			/*
+			 * Reject window sizes larger than the kernel buffer
+			 * allocated at probe time, otherwise subsequent
+			 * read/write would access memory beyond kern_buf.
+			 * Also reject size == 0 to prevent integer underflow
+			 * in the boundary check (*ppos > image_size - 1).
+			 */
+			if (slave.size == 0 || slave.size > image[minor].size_buf)
+				return -EINVAL;
+
 			/* XXX	We do not want to push aspace, cycle and width
 			 *	to userspace as they are
 			 */
-- 
2.43.0

      reply	other threads:[~2026-05-14  3:45 UTC|newest]

Thread overview: 8+ 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       ` Rion Kiguchi [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=20260514034511.4244-1-kiguchi.r.sec@gmail.com \
    --to=kiguchi.r.sec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --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.