CVE-2026-90190: null_blk: use DEFINE_MUTEX for the file-scope mutex
In the Linux kernel, the following vulnerability has been resolved:
nullblk: use DEFINEMUTEX for the file-scope mutex
In nullinit(), mutexinit(&lock) currently happens after configfsregistersubsystem(), which exposes the nullb subsystem to userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach nullfinddevbyname() -> mutexlock(&lock) before the mutex is initialized, trigger warning:
[ 123.137788] DEBUGLOCKSWARNON(lock->magic != lock) [ 123.137796] WARNING: kernel/locking/mutex.c:159 at mutexlock+0x171/0x1c0, CPU#13: mkdir/1301 [ 123.140090] Modules linked in: nullblk(+) nftfibinet nftfibipv4 ...... [ 123.154926] Call Trace: [ 123.155172] <TASK> [ 123.155419] ? pfxmutexlock+0x10/0x10 [ 123.156181] ? pfxrawspinlock+0x10/0x10 [ 123.156571] nullbgroupmakegroup+0x20/0x100 [nullblk] [ 123.157011] configfsmkdir+0x47b/0xc70 [ 123.157337] ? pfxconfigfsmkdir+0x10/0x10 [ 123.157719] ? maycreatedentry+0x242/0x2e0 [ 123.158061] vfsmkdir+0x2a9/0x6c0 [ 123.158352] filenamemkdirat+0x3dc/0x500 [ 123.158710] ? pfxfilenamemkdirat+0x10/0x10 [ 123.159070] ? strncpyfromuser+0x3a/0x1d0 [ 123.159413] x64sysmkdir+0x6b/0x90 [ 123.159760] dosyscall64+0xea/0x600
Replace the runtime mutexinit(&lock) with a static DEFINEMUTEX(lock) declaration to fix this issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the kernel null_blk nullb subsystem code to replace the runtime mutex_init(&lock) call in null_init() with a file-scope static DEFINE_MUTEX(lock) so that mutex_lock(&lock) is never reached before the mutex is initialized (prevents the DEBUG_LOCKS/WARNING sequence shown in kernel/locking/mutex.c).
Linux kernel (null_blk / configfs nullb subsystem) Replace runtime mutex_init(&lock) with static DEFINE_MUTEX(lock) = DEFINE_MUTEX(lock)
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
The null_blk subsystem must be exposed through configfs, and a userspace process must race a mkdir operation in /sys/kernel/config/nullb/ while null_init() is still running and before its file-scope mutex has been initialized.
How can administrators identify a possible occurrence?
A triggered race can produce a DEBUG_LOCKS_WARN_ON(lock->magic != lock) warning at mutex_lock, with a call trace involving nullb_group_make_group, configfs_mkdir, and mkdir. The null_blk module may also appear in the loaded-modules portion of the warning output.