Linux block layer
 help / color / mirror / Atom feed
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


             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