All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rion Kiguchi <kiguchi.r.sec@gmail.com>
To: kiguchi.r.sec@gmail.com
Cc: stable@vger.kernel.org
Subject: [PATCH] staging: vme_user: validate slave window size against buffer size
Date: Sat,  9 May 2026 16:53:18 +0900	[thread overview]
Message-ID: <20260509075318.640383-1-kiguchi.r.sec@gmail.com> (raw)

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;
+	}
 	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;
+	}
 	image_ptr = image[minor].kern_buf + *ppos;
 	if (copy_from_user(image_ptr, buf, (unsigned long)count))
 		return -EFAULT;
@@ -394,6 +404,14 @@ 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.
+			 */
+			if (slave.size > image[minor].size_buf)
+				return -EINVAL;
+
 			/* XXX	We do not want to push aspace, cycle and width
 			 *	to userspace as they are
 			 */
@@ -401,7 +419,6 @@ static int vme_user_ioctl(struct inode *inode, struct file *file,
 				slave.enable, slave.vme_addr, slave.size,
 				image[minor].pci_buf, slave.aspace,
 				slave.cycle);
-
 			break;
 		}
 		break;
-- 
2.43.0


             reply	other threads:[~2026-05-09  7:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-09  7:53 Rion Kiguchi [this message]
2026-05-09  8:04 ` [PATCH] staging: vme_user: validate slave window size against buffer size 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
  -- 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=20260509075318.640383-1-kiguchi.r.sec@gmail.com \
    --to=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.