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.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
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.