CVE-2026-90190 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
null_blk: use DEFINE_MUTEX for the file-scope mutex
In null_init(), mutex_init(&lock) currently happens after configfs_register_subsystem(), which exposes the nullb subsystem to userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach null_find_dev_by_name() -> mutex_lock(&lock) before the mutex is initialized, trigger warning:
[ 123.137788] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 123.137796] WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0, CPU#13: mkdir/1301
[ 123.140090] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4
...... [ 123.154926] Call Trace:
[ 123.155172] <TASK>
[ 123.155419] ? __pfx_mutex_lock+0x10/0x10
[ 123.156181] ? __pfx__raw_spin_lock+0x10/0x10
[ 123.156571] nullb_group_make_group+0x20/0x100 [null_blk]
[ 123.157011] configfs_mkdir+0x47b/0xc70
[ 123.157337] ? __pfx_configfs_mkdir+0x10/0x10
[ 123.157719] ? may_create_dentry+0x242/0x2e0
[ 123.158061] vfs_mkdir+0x2a9/0x6c0
[ 123.158352] filename_mkdirat+0x3dc/0x500
[ 123.158710] ? __pfx_filename_mkdirat+0x10/0x10
[ 123.159070] ? strncpy_from_user+0x3a/0x1d0
[ 123.159413] __x64_sys_mkdir+0x6b/0x90
[ 123.159760] do_syscall_64+0xea/0x600
Replace the runtime mutex_init(&lock) with a static DEFINE_MUTEX(lock) declaration to fix this issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability in question resides within the null_blk driver of the Linux kernel, specifically involving an initialization race condition that can lead to undefined behavior and potential system instability. The core technical flaw stems from the ordering of operations during the module's initialization phase. In the original implementation, the mutex used for synchronizing access to internal data structures was initialized using a runtime call to mutex_init within the null_init function. This initialization occurred after the configfs subsystem had already been registered with the kernel. ConfigFS is a virtual filesystem that allows userspace applications to interact with and configure kernel objects dynamically. By registering this subsystem before ensuring all associated synchronization primitives are ready, the driver inadvertently exposes its internal interfaces to user-space manipulation while still in an uninitialized state.
This ordering error creates a specific window of vulnerability where a concurrent operation can trigger a critical failure. When a userspace process attempts to create a new directory entry under /sys/kernel/config/nullb/ using the mkdir system call, it invokes configfs_mkdir, which subsequently calls into nullb_group_make_group within the null_blk driver. This function relies on acquiring a lock via mutex_lock(&lock) to ensure thread-safe access to device structures through null_find_dev_by_name(). However, because the initialization of this mutex happens later in the init sequence, there is a possibility that a user-space request arrives and attempts to acquire the lock before it has been properly initialized. Accessing an uninitialized mutex results in invalid memory operations or logic errors within the locking subsystem, triggering kernel warnings such as DEBUG_LOCKS_WARN_ON(lock->magic != lock) and potentially causing a crash or unpredictable behavior depending on the specific state of the corrupted data structures.
From a security perspective, this issue is classified under CWE-362, which describes concurrent execution using shared resources with improper synchronization. The race condition allows an unprivileged user-space process to interact with kernel memory in an unsafe manner during the initialization window. While the immediate impact manifests as a denial of service through kernel warnings or crashes, such races can sometimes be exploited for more severe outcomes if they lead to use-after-free scenarios or corruption of critical kernel data structures that persist beyond the initial crash. The vulnerability aligns with ATT&CK techniques related to resource hijacking and potential privilege escalation vectors where instability in core subsystems is leveraged to disrupt service availability or manipulate system state.
The resolution involves a straightforward but effective code modification: replacing the runtime mutex_init(&lock) call with a static DEFINE_MUTEX(lock declaration at file scope. This change ensures that the mutex is initialized statically when the module is loaded, prior to any dynamic registration of subsystems like configfs. By guaranteeing that the synchronization primitive is fully operational before the interface becomes accessible to userspace, the race condition is eliminated entirely. This approach adheres to best practices for kernel development by separating static initialization from runtime configuration steps.
To mitigate similar issues in other parts of the system or future developments, developers should ensure that all synchronization primitives associated with a subsystem are initialized before exposing any interfaces to user-space interaction. Auditing code paths where configfs or sysfs entries are registered is essential to verify that no concurrent access can occur during the initialization phase. Additionally, employing static analysis tools and runtime lock debugging features like DEBUG_LOCKS can help identify such ordering violations early in the development cycle. Maintaining strict adherence to initialization order ensures system stability and prevents exploitation of timing-dependent flaws in kernel modules.