ublk: hold RCU read lock in ublk_try_buf_match()

syzbot reports a lockdep splat when I/O is dispatched to a ublk device
with UBLK_F_SHMEM_ZC enabled:

  WARNING: suspicious RCU usage
  lib/maple_tree.c:720 suspicious rcu_dereference_check() usage!
  ...
  Call Trace:
   mas_root lib/maple_tree.c:720 [inline]
   mas_start+0x3cc/0x640 lib/maple_tree.c:1250
   mas_state_walk lib/maple_tree.c:3006 [inline]
   mas_walk+0x1db/0x490 lib/maple_tree.c:4458
   ublk_try_buf_match drivers/block/ublk_drv.c:5639 [inline]
   ublk_init_iod+0x5d2/0x1120 drivers/block/ublk_drv.c:521
   ublk_dispatch_req+0x97/0x9c0 drivers/block/ublk_drv.c:1776
   tctx_task_work_run+0x73d/0xa80 io_uring/tw.c:96

ublk_try_buf_match() calls mas_walk() on the buffer tree without
holding the RCU read lock or the tree lock. Writers are already
excluded because ublk_lock_buf_tree() freezes the queue, so there is
no real race, but maple tree readers must still hold one of the two.

Take the RCU read lock around the walk.

Fixes: 4d4a512a1f ("ublk: add PFN-based buffer matching in I/O path")
Reported-by: syzbot+b48868c46e62c1c4cb2c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b48868c46e62c1c4cb2c
Assisted-by: LLM
Signed-off-by: Paolo Bertinetti <paolobertinetti200f4@proton.me>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Link: https://patch.msgid.link/179010105967.8478.2344875677216734809@proton.me
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This commit is contained in:
Paolo Bertinetti 2026-09-22 18:17:43 +00:00 committed by Jens Axboe
parent 1b1be9ea4e
commit aaf4902304

View File

@ -5633,6 +5633,8 @@ static bool ublk_try_buf_match(struct ublk_device *ub,
unsigned long expected_offset = 0;
bool first = true;
guard(rcu)();
rq_for_each_bvec(bv, rq, iter) {
unsigned long pfn = page_to_pfn(bv.bv_page);
unsigned long end_pfn = pfn +