CVE-2026-90337 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
serial: core: do fallible allocations before the console can be registered
serial_core_add_one_port() allocates uport->tty_groups after uart_configure_port(), which may register the console. If the allocation fails, the driver unwinds the port while its console remains registered. The earlier uport->name allocation has a related failure path that leaves state->uart_port linked to a port being freed.
Failslab reproduced a NULL dereference in PL011 console output and a KASAN use-after-free in i.MX console output after failed binds.
Allocate the name and tty_groups before linking the port and configuring it. Reserve space for the optional driver attribute group because config_port() may populate uport->attr_group during configuration.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel serial core subsystem represents a critical resource management flaw rooted in improper allocation sequencing relative to system state transitions. Specifically, the function serial_core_add_one_port performs memory allocations for internal structures such as tty_groups and port names after the uart_configure_port routine has already executed. This ordering is problematic because uart_configure_port possesses the capability to register the console associated with the serial port during its execution phase. Consequently, if a subsequent allocation fails due to resource exhaustion or other constraints, the error handling logic attempts to unwind the port state while the console remains actively registered and potentially in use by the kernel logging infrastructure. This race condition between memory deallocation and active console usage creates an unstable system state that can lead to severe stability issues including NULL pointer dereferences and use-after-free conditions, as evidenced by failures observed with PL011 and i.MX serial drivers under stress testing scenarios like failslab simulations.
From a technical perspective, the core issue lies in the dependency between driver initialization steps and memory availability. The uart_configure_port function may populate uport->attr_group or trigger console registration mechanisms that rely on valid pointers within the port structure. When allocations for essential components like uport->name and tty_groups occur after this configuration step, a failure results in partial cleanup where some resources are freed while others remain linked to active kernel subsystems. This leaves state->uart_port pointing to memory regions that are being deallocated or invalidating references held by the console output routines. The resulting use-after-free vulnerability allows for potential information disclosure or denial of service through kernel panic, and under specific exploitation conditions involving crafted inputs or sustained resource pressure, could potentially lead to arbitrary code execution if an attacker can control the contents of the freed memory before it is reallocated for malicious purposes.
The operational impact of this flaw extends beyond immediate system crashes. It affects the reliability of serial communication interfaces which are often critical for embedded systems, industrial controllers, and debugging consoles where consistent availability is paramount. A NULL dereference in console output can halt logging capabilities during boot or runtime diagnostics, obscuring other errors and complicating troubleshooting efforts. Furthermore, use-after-free vulnerabilities pose significant security risks by allowing attackers to manipulate kernel memory structures through heap spraying techniques or timing attacks, potentially escalating privileges from unprivileged user space to ring zero. This aligns with common weakness enumerations related to improper resource management and race conditions in concurrent environments.
To mitigate this vulnerability, the resolution involves reordering the allocation sequence within serial_core_add_one_port so that all necessary memory resources are secured before any configuration or registration steps occur. By allocating uport->name and tty_groups prior to linking the port structure into global lists and invoking uart_configure_port, the driver ensures that if an allocation fails, no console has been registered yet, allowing for safe cleanup without leaving dangling references in active subsystems. Additionally, reserving space for optional driver attribute groups during initial configuration prevents scenarios where config_port might attempt to access uninitialized or freed memory regions. This approach adheres to best practices outlined in CWE-362 regarding concurrent execution issues and CWE-416 concerning use-after-free conditions, ensuring that resource lifecycles are strictly managed relative to their usage contexts within the kernel architecture.