From: Cen Zhang <zzzccc427@gmail.com>
To: Jens Axboe <axboe@kernel.dk>, Keith Busch <kbusch@kernel.org>,
Johannes Thumshirn <johannes.thumshirn@wdc.com>,
Chaitanya Kulkarni <kch@nvidia.com>,
Damien Le Moal <dlemoal@kernel.org>,
Genjian Zhang <zhanggenjian@kylinos.cn>,
Hans Holmberg <hans.holmberg@wdc.com>,
Nilay Shroff <nilay@linux.ibm.com>, Kees Cook <kees@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
Kyungchan Koh <kkc6196@fb.com>, Shaohua Li <shli@fb.com>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
baijiaju1990@gmail.com, zzzccc427@gmail.com
Subject: [PATCH] null_blk: cancel bw_timer on add-device error unwind
Date: Wed, 24 Jun 2026 15:18:25 +0800 [thread overview]
Message-ID: <20260624071825.357098-1-zzzccc427@gmail.com> (raw)
null_blk starts the bandwidth hrtimer before the later add_disk/device_add
failure points. If setup fails after the timer is queued, the shared error
unwind frees struct nullb without draining bw_timer, so the callback can
run on freed owner state.
The buggy scenario involves two paths, with each column showing the order
within that path:
null_add_dev() error unwind: nullb_bwtimer_fn() callback path:
1. Start bw_timer for a throttled 1. The hrtimer expires after the free.
device. 2. nullb_bwtimer_fn() recovers the
2. Hit a later add_disk/device_add embedded owner.
failure. 3. The callback reads nullb->dev and
3. Free struct nullb. nullb->q.
4. Release the remaining queue and 4. The stale owner storage is used
disk resources. after free.
Cancel bw_timer in the shared error unwind before put_disk() and the
remaining frees. The normal delete path already uses the same
hrtimer_cancel() drain.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in nullb_bwtimer_fn+0x13f/0x170 [null_blk]
Call Trace:
<IRQ>
dump_stack_lvl+0x66/0xa0
print_report+0xce/0x630
? nullb_bwtimer_fn+0x13f/0x170 [null_blk]
? srso_alias_return_thunk+0x5/0xfbef5
? __virt_addr_valid+0x20d/0x410
? nullb_bwtimer_fn+0x13f/0x170 [null_blk]
kasan_report+0xe0/0x110
? nullb_bwtimer_fn+0x13f/0x170 [null_blk]
? __pfx_nullb_bwtimer_fn+0x10/0x10 [null_blk]
nullb_bwtimer_fn+0x13f/0x170 [null_blk]
__hrtimer_run_queues+0x172/0x810
hrtimer_interrupt+0x377/0x7f0
__sysvec_apic_timer_interrupt+0xc3/0x390
sysvec_apic_timer_interrupt+0x67/0x80
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20
Allocated by task 529:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0xaa/0xb0
null_add_dev+0x4f9/0x1d10 [null_blk]
nullb_device_power_store+0x25f/0x320 [null_blk]
configfs_write_iter+0x2be/0x4a0
vfs_write+0x604/0x11f0
ksys_write+0xf9/0x1d0
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 529:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x5f/0x80
kfree+0x307/0x580
null_add_dev+0x1272/0x1d10 [null_blk]
nullb_device_power_store+0x25f/0x320 [null_blk]
configfs_write_iter+0x2be/0x4a0
vfs_write+0x604/0x11f0
ksys_write+0xf9/0x1d0
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fixes: eff2c4f10873 ("nullb: bandwidth control")
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
drivers/block/null_blk/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c
index f8c0fd57e041..8f1ad76710a0 100644
--- a/drivers/block/null_blk/main.c
+++ b/drivers/block/null_blk/main.c
@@ -2062,6 +2062,8 @@ static int null_add_dev(struct nullb_device *dev)
out_ida_free:
ida_free(&nullb_indexes, nullb->index);
out_cleanup_disk:
+ if (test_bit(NULLB_DEV_FL_THROTTLED, &dev->flags))
+ hrtimer_cancel(&nullb->bw_timer);
put_disk(nullb->disk);
out_cleanup_zone:
null_free_zoned_dev(dev);
--
2.43.0
next reply other threads:[~2026-06-24 7:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 7:18 Cen Zhang [this message]
2026-06-24 14:21 ` [PATCH] null_blk: cancel bw_timer on add-device error unwind Nilay Shroff
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=20260624071825.357098-1-zzzccc427@gmail.com \
--to=zzzccc427@gmail.com \
--cc=axboe@kernel.dk \
--cc=baijiaju1990@gmail.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=dlemoal@kernel.org \
--cc=hans.holmberg@wdc.com \
--cc=johannes.thumshirn@wdc.com \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=kees@kernel.org \
--cc=kkc6196@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nilay@linux.ibm.com \
--cc=shli@fb.com \
--cc=willy@infradead.org \
--cc=zhanggenjian@kylinos.cn \
/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