CVE-2024-50058 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
serial: protect uart_port_dtr_rts() in uart_shutdown() too
Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports.
Or it cannot be NULL at this point at all for some reason :P.
Until the above is investigated, stay on the safe side and move this dereference to the if too.
I got this inconsistency from Coverity under CID 1585130. Thanks.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 03/23/2026
The vulnerability CVE-2024-50058 represents a potential null pointer dereference in the Linux kernel's serial communication subsystem, specifically within the uart_shutdown() function of the serial core driver. This issue arises from an inconsistent code pattern where the function properly checks for null uart_port structures but fails to protect subsequent operations that assume the structure remains valid. The problem manifests when the HUPCL (Hang Up on Close) flag is set, triggering a call to uart_port_dtr_rts(uport, false) that occurs after the initial null check but before the function properly validates the port state. This inconsistency creates a potential race condition or logic error where a null pointer dereference could occur if the port structure becomes invalid between the initial check and the subsequent operation.
The technical flaw stems from improper code flow control within the serial port shutdown mechanism, where the kernel's serial core attempts to manage hardware handshaking signals through DTR (Data Terminal Ready) and RTS (Request To Send) lines. When HUPCL is enabled, the system should clear these handshaking lines to properly terminate serial communication, but the current implementation fails to maintain proper null pointer validation throughout the entire execution path. This vulnerability falls under CWE-476 which describes NULL Pointer Dereference, and specifically relates to improper handling of resource access patterns in kernel space. The issue was identified through static analysis by Coverity under CID 1585130, indicating the problem exists in the code's logical flow rather than a simple missing check.
The operational impact of this vulnerability could be significant in embedded systems or server environments where serial communication is critical for system management, device control, or debugging operations. An attacker could potentially exploit this race condition to cause system instability, denial of service, or in rare cases, privilege escalation if the null pointer dereference leads to memory corruption. The vulnerability is particularly concerning because it affects the kernel's serial subsystem which is fundamental to many system operations, including console output, modem communications, and hardware device interfacing. Systems running affected kernel versions may experience crashes or unpredictable behavior when serial ports are shut down, especially under concurrent access conditions or during system shutdown procedures.
The recommended mitigation strategy involves applying the kernel patch that moves the uart_port_dtr_rts() call within the existing null pointer check block, ensuring that all operations on the uart_port structure occur only when the structure is guaranteed to be valid. This approach follows the principle of defensive programming and aligns with the kernel's established patterns for resource management. Administrators should prioritize updating to kernel versions that include the fix, particularly in production environments where serial communication is heavily utilized. Additionally, system administrators should monitor for any unusual system behavior or crashes that might indicate exploitation attempts, and consider implementing proper system hardening measures including kernel lockdown configurations and access controls to limit potential attack surfaces. The fix represents a straightforward code restructuring that eliminates the logical inconsistency while maintaining all existing functionality and system behavior.