From: Ming Lei <ming.lei@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org,
Caleb Sander Mateos <csander@purestorage.com>
Subject: Re: [PATCH V2] ublk: use unchecked copy helpers for bio page data
Date: Wed, 1 Apr 2026 23:36:28 +0800 [thread overview]
Message-ID: <ac07fNyWOrX5PcUa@fedora> (raw)
In-Reply-To: <f10b5a3d-33f9-486c-b8e9-6d9286448f69@kernel.dk>
On Wed, Apr 01, 2026 at 09:19:23AM -0600, Jens Axboe wrote:
> On 3/31/26 7:24 PM, Ming Lei wrote:
> > Bio pages may originate from slab caches that lack a usercopy region
> > (e.g. jbd2 frozen metadata buffers allocated via jbd2_alloc()).
> > When CONFIG_HARDENED_USERCOPY is enabled, copy_to_iter() calls
> > check_copy_size() which rejects these slab pages, triggering a
> > kernel BUG in usercopy_abort().
> >
> > This is a false positive: the data is ordinary block I/O content ?
> > the same data the loop/nbd driver writes to its backing file via
> > vfs_iter_write(). The bvec length is always trusted, so the size
> > check in check_copy_size() is not needed either.
> >
> > Switch to _copy_to_iter()/_copy_from_iter() which skip the
> > check_copy_size() wrapper while the underlying copy_to_user()
> > remains unchanged.
> >
> > Fixes: 2299ceec364e ("ublk: use copy_{to,from}_iter() for user copy")
> > Signed-off-by: Ming Lei <ming.lei@redhat.com>
> > ---
> > V2:
> > - update commit log (Caleb Sander Mateos)
> >
> > drivers/block/ublk_drv.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> > index 2e475bdc54dd..3e329906ae19 100644
> > --- a/drivers/block/ublk_drv.c
> > +++ b/drivers/block/ublk_drv.c
> > @@ -1322,10 +1322,18 @@ static bool ublk_copy_user_bvec(const struct bio_vec *bv, unsigned *offset,
> >
> > len = bv->bv_len - *offset;
> > bv_buf = kmap_local_page(bv->bv_page) + bv->bv_offset + *offset;
> > + /*
> > + * Bio pages may originate from slab caches without a usercopy region
> > + * (e.g. jbd2 frozen metadata buffers). This is the same data that
> > + * the loop driver writes to its backing file ? no exposure risk.
> > + * The bvec length is always trusted, so the size check in
> > + * check_copy_size() is not needed either. Use the unchecked
> > + * helpers to avoid false positives on slab pages.
> > + */
> > if (dir == ITER_DEST)
> > - copied = copy_to_iter(bv_buf, len, uiter);
> > + copied = _copy_to_iter(bv_buf, len, uiter);
> > else
> > - copied = copy_from_iter(bv_buf, len, uiter);
> > + copied = _copy_from_iter(bv_buf, len, uiter);
> >
> > kunmap_local(bv_buf);
>
> Is this just a jbd2 issue? Because we can just get the slab marked
> appropriately to not trigger these warnings.
If the ublk block device is permitted to mount FS, it is inevitable to expose
the meta to ublk userspace daemon, same with loop, or other block device.
Any bio pages backed by slab without a usercopy need to bypass the size check,
which isn't necessary too.
thanks,
Ming
prev parent reply other threads:[~2026-04-01 15:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 1:24 [PATCH V2] ublk: use unchecked copy helpers for bio page data Ming Lei
2026-04-01 15:15 ` Caleb Sander Mateos
2026-04-01 15:19 ` Jens Axboe
2026-04-01 15:36 ` Ming Lei [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=ac07fNyWOrX5PcUa@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=linux-block@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox