drivers/block/ublk_drv.c | 2 ++ 1 file changed, 2 insertions(+)
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: 4d4a512a1f87 ("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>
---
syzbot tested this patch [1]: the RCU splat is gone, but the reproducer
then hits the already open "WARNING in io_wq_put_and_exit (2)" [2],
which syzbot has been reporting since May on kernels without this change.
[1] https://lore.kernel.org/all/6ab1eabe.71f81b7d.15fa6d.003b.GAE@google.com/
[2] https://syzkaller.appspot.com/bug?extid=b0d54b9e81de55179e47
drivers/block/ublk_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index 66eb55e71..7a64745e1 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -5628,6 +5628,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 +
base-commit: 93f51579e7df248780214094418f205253383cc5
--
2.55.0
On Tue, Sep 22, 2026 at 1:17 PM Paolo Bertinetti
<paolobertinetti200f4@proton.me> wrote:
>
> 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: 4d4a512a1f87 ("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>
> ---
> syzbot tested this patch [1]: the RCU splat is gone, but the reproducer
> then hits the already open "WARNING in io_wq_put_and_exit (2)" [2],
> which syzbot has been reporting since May on kernels without this change.
>
> [1] https://lore.kernel.org/all/6ab1eabe.71f81b7d.15fa6d.003b.GAE@google.com/
> [2] https://syzkaller.appspot.com/bug?extid=b0d54b9e81de55179e47
>
> drivers/block/ublk_drv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index 66eb55e71..7a64745e1 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -5628,6 +5628,8 @@ static bool ublk_try_buf_match(struct ublk_device *ub,
> unsigned long expected_offset = 0;
> bool first = true;
>
> + guard(rcu)();
> +
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Thanks
Ming Lei
© 2016 - 2026 Red Hat, Inc.