CVE-2026-90189: null_blk: register configfs subsystem after creating default devices
In the Linux kernel, the following vulnerability has been resolved:
nullblk: register configfs subsystem after creating default devices
In nullinit(), configfsregistersubsystem() currently runs before registerblkdev(), so when nullblk is built as a module, a racing mkdir() + poweron from userspace can reach nulladddev() while nullmajor is still 0. adddisk() then hits WARNON(disk->minors) (major=0 with minors!=0) and fails:
[root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at adddisk+0x8a7/0xde0, [ 2366.523552] Modules linked in: nullblk(+) nftfibinet nftfibipv4 nftfibipv6 nftfib [ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full) ...... [ 2366.547251] Call Trace: [ 2366.547575] <TASK> [ 2366.547831] ? rawspinlock+0x84/0xe0 [ 2366.548260] adddiskfwnode+0x114/0x560 [ 2366.548739] nulladddev+0x102d/0x1b80 [nullblk] [ 2366.549310] ? pfxnulladddev+0x10/0x10 [nullblk] [ 2366.549906] ? mutexlock+0xde/0x1c0 [ 2366.550361] ? pfxmutexlock+0x10/0x10 [ 2366.550827] nullbdevicepowerstore+0x1e7/0x280 [nullblk] [ 2366.551499] ? pfxnullbdevicepowerstore+0x10/0x10 [nullblk] [ 2366.552177] ? kmalloccachenoprof+0x1f5/0x470 [ 2366.552748] ? configfswriteiter+0x35c/0x4e0 [ 2366.553242] configfswriteiter+0x286/0x4e0 [ 2366.553787] vfswrite+0x52d/0xd00 [ 2366.554169] ? pfxvfswrite+0x10/0x10 [ 2366.554679] ? pfxcssrstatupdated+0x10/0x10 [ 2366.555196] ? fdgetpos+0x1cf/0x4c0 [ 2366.555649] ksyswrite+0xfc/0x1d0 ......
Additionally, the errdev path destroys all devices on nullblist while configfs is still registered. If a racing mkdir() + poweron puts a user device on the list, nulldestroydev()->nullfreedev() kfrees the user device's nullbdevice but /sys/kernel/config/nullb/<name> is still reachable. Any userspace access to the item will trigger a UAF.
For simplicity, move configfsregistersubsystem() to the end to solve the problems above.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this race condition?
Systems that load null_blk as a module and allow userspace to create and power on null_blk devices through configfs during module initialization are exposed. The described trigger requires a race between those userspace actions and completion of block-device registration.
What does an attacker or local user need to do to trigger it?
They need to race a configfs mkdir() and poweron operation so that null_add_dev() runs before null_major has been assigned by register_blkdev(). The supplied example shows this can cause a kernel warning and failure when adding the disk.
Are default null_blk devices implicated?
Yes. The fix changes initialization so the configfs subsystem is registered only after default devices are created, preventing configfs userspace operations from reaching device creation too early.