From: Rion Kiguchi <kiguchi.r.sec@gmail.com>
To: kiguchi.r.sec@gmail.com
Cc: stable@vger.kernel.org
Subject: [PATCH v3] staging: vme_user: validate slave window size against buffer size
Date: Sat, 9 May 2026 18:07:21 +0900 [thread overview]
Message-ID: <20260509090721.1136091-1-kiguchi.r.sec@gmail.com> (raw)
In-Reply-To: <2026050935-designing-glancing-2e16@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.
The subsequent read() / write() handlers (vme_user_read /
vme_user_write) clamp the I/O range against vme_get_size(), which
returns the size the bridge driver has programmed for the window
(i.e. the attacker-supplied slave.size). vme_get_size() does not
consult size_buf, so an oversized window passes the existing bounds
checks, and buffer_to_user() / buffer_from_user() then index
image[minor].kern_buf with 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 > 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; no additional checks in
buffer_to_user() / buffer_from_user() are needed.
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 | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/vme_user/vme_user.c b/drivers/staging/vme_user/vme_user.c
index 11e25c2f6..6fd051f49 100644
--- a/drivers/staging/vme_user/vme_user.c
+++ b/drivers/staging/vme_user/vme_user.c
@@ -394,6 +394,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 +409,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
next prev parent reply other threads:[~2026-05-09 9:08 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 ` Rion Kiguchi [this message]
2026-05-09 9:15 ` [PATCH v3] " 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
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=20260509090721.1136091-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.