UBUNTU-CVE-2026-90190: Medium severity ubuntu/linux-hwe-edge vulnerability
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
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 - Configuration
Replace the runtime mutex_init(&lock) with a static DEFINE_MUTEX(lock) declaration so the mutex is initialized before configfs_register_subsystem() exposes the nullb subsystem to userspace.
Linux kernel null_blk file-scope lock initialization = 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 to create a directory under /sys/kernel/config/nullb/ while null_blk initialization has registered the configfs subsystem but has not yet initialized its file-scope mutex.
Who can realistically trigger it?
A local userspace process able to issue mkdir operations in the null_blk configfs hierarchy can trigger the race. The provided trace shows the issue occurring during mkdir through configfs_mkdir and nullb_group_make_group.
How can I tell whether a system has encountered the issue?
Kernel logs may contain a DEBUG_LOCKS_WARN_ON message stating "lock->magic != lock" and a warning at kernel/locking/mutex.c:159 in mutex_lock. The stack trace can include nullb_group_make_group, configfs_mkdir, and __x64_sys_mkdir.