CVE-2026-90158 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
m68k: nfcon: Do not call console_is_registered() in nfcon_device()
Since 7c2af0f634f1 ("tty: tty_io: use console_list_lock for list synchronization") show_cons_active() calls the .device() method under the console_list_lock, but console_is_registered() tries to acquire console_list_lock as well, causing a deadlock. It should not be necessary to check console_is_registered() here since the function should not be called in the fist place when the console is not registered.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified involves a concurrency issue within the m68k architecture's nfcon driver, specifically resulting from an improper locking strategy during device initialization and status checks. The root cause lies in the interaction between the tty subsystem's synchronization mechanisms and the specific implementation of the console_is_registered function. Since commit 7c2af0f634f1, which updated tty_io to use console_list_lock for list synchronization, the show_cons_active routine invokes the .device method while holding this lock. However, within nfcon_device, there was a call to console_is_registered, which independently attempts to acquire the same console_list_lock. This nested locking scenario creates a classic deadlock condition where the thread holds one instance of the lock and waits for another that is already held by itself or in an incompatible state due to non-recursive locking semantics inherent in many kernel mutex implementations.
From a technical perspective, this flaw represents a violation of proper resource acquisition ordering and recursive locking protocols. The nfcon_device function was designed to verify if the console subsystem had registered its presence before proceeding with device-specific operations. While such checks are common for robustness, they become hazardous when performed under an existing lock context that is also required by the check itself. This specific implementation detail in the tty layer changed the execution environment of drivers like nfcon, exposing latent concurrency bugs where developers assumed exclusive access or did not account for locks held by callers. The deadlock effectively halts kernel progress on affected systems, potentially leading to system hangs during boot sequences or when console devices are dynamically managed, thereby impacting availability and stability.
The operational impact of this vulnerability is primarily centered around system reliability and availability. When the nfcon driver attempts to register or query its status while show_cons_active holds the console_list_lock, the kernel enters a deadlock state. This can manifest as a frozen system during early boot processes where consoles are being initialized, or potentially during runtime if dynamic device management triggers similar code paths. For administrators running m68k-based systems with this specific driver configuration, such an event results in complete loss of interactive access and requires manual intervention to reboot the machine. It does not typically allow for remote exploitation by attackers but serves as a significant stability risk that can be triggered through normal system operation or stress testing of console subsystems.
Mitigation strategies involve applying the upstream kernel patch that removes the unnecessary call to console_is_registered within nfcon_device. The rationale provided in the fix indicates that this check is redundant because the function should not be invoked if the console is not registered, implying that the caller already ensures valid context or that the registration state is implicitly guaranteed by the execution path. By eliminating this superfluous lock acquisition attempt, the deadlock condition is resolved without compromising security boundaries. Administrators and developers must ensure they are running a patched version of the Linux kernel where this specific concurrency fix has been integrated into the m68k architecture support code. Regularly updating to stable kernel releases that include tty subsystem synchronization improvements is essential to prevent similar locking issues in other drivers that may interact with console infrastructure under lock-held contexts.
This vulnerability aligns with CWE-764, which covers multiple locks being acquired on the same resource, and specifically relates to improper handling of recursive or nested locking scenarios. In terms of attack vectors, it falls under availability impacts rather than confidentiality or integrity breaches, as it disrupts service through self-deadlocking mechanisms. The ATT&CK framework does not directly map this kernel-level concurrency bug to a specific adversary technique since it is an internal implementation flaw rather than an external exploit vector, but it highlights the importance of rigorous code review for locking patterns in critical subsystems like tty and console management. Ensuring that drivers do not acquire locks already held by their callers or related synchronization primitives is a fundamental best practice in kernel development to maintain system stability under high-concurrency conditions.