From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: 木口璃音 <kiguchi.r.sec@gmail.com>
Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, security@kernel.org
Subject: Re: [PATCH] staging: vme_user: validate slave window size against buffer size
Date: Sat, 9 May 2026 09:15:42 +0200 [thread overview]
Message-ID: <2026050931-brewing-suffice-fa3f@gregkh> (raw)
In-Reply-To: <CAKs+XO1WXrv4jvNuEyMxu-iP9E-fifJLwOZ1nJynDjpvfn2n=g@mail.gmail.com>
On Sat, May 09, 2026 at 03:58:45PM +0900, 木口璃音 wrote:
> This patch addresses the OOB read/write reported earlier
> in the security@kernel.org thread (now handled publicly per
> Greg's and Willy's guidance).
>
> Tested on Linux 7.1.0-rc2 with KASAN; all three reproducers
> fail with -EINVAL after applying this patch and produce no
> KASAN splat.
>
> >From 506ecfc9b8608fb3a56477b8fd205238a1bf66ff Mon Sep 17 00:00:00 2001
> From: Rion Kiguchi <kiguchi.r.sec@gmail.com>
> Date: Sat, 9 May 2026 15:38:33 +0900
> Subject: [PATCH] staging: vme_user: validate slave window size against buffer
> size
This all doesn't belong in the body of the email, please just use git
send-email to send the patch.
>
> 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.
>
> Reported-by: Pochix1103 <kiguchi.r.sec@gmail.com>
Ok, but:
> Cc: stable@vger.kernel.org
> Signed-off-by: Rion Kiguchi <kiguchi.r.sec@gmail.com>
You don't have a reported-by and a signed-off-by for the same thing, if
you author and sign off, it's implied you are reporting the issue :)
Also, you have to document the AI tool you used to find and fix this as
per out documentation.
thanks,
greg k-h
next prev parent reply other threads:[~2026-05-09 7:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-09 6:58 [PATCH] staging: vme_user: validate slave window size against buffer size 木口璃音
2026-05-09 7:15 ` gregkh [this message]
2026-05-09 7:17 ` gregkh
-- strict thread matches above, loose matches on Subject: below --
2026-05-09 7:53 Rion Kiguchi
2026-05-09 8:04 ` Greg KH
2026-05-09 8:02 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=2026050931-brewing-suffice-fa3f@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=kiguchi.r.sec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=security@kernel.org \
--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.