CVE-2024-27000 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
serial: mxs-auart: add spinlock around changing cts state
The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.
[ 85.119255] ------------[ cut here ]------------
[ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
[ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
[ 85.151396] Hardware name: Freescale MXS (Device Tree)
[ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]
(...) [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
[ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
(...)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/06/2026
The vulnerability CVE-2024-27000 represents a concurrency issue within the Linux kernel's serial communication subsystem, specifically affecting the mxs-auart driver used on i.MX28 boards. This flaw manifests as a race condition in the handling of Clear-to-Send (CTS) signal state changes, where the uart_handle_cts_change() function in serial_core expects callers to hold the uport->lock mutex for proper synchronization. The issue occurs when multiple threads attempt to modify the CTS state simultaneously without proper locking mechanisms, leading to potential data corruption and system instability. The vulnerability is particularly concerning in embedded systems environments where real-time communication protocols like Bluetooth are heavily utilized, as demonstrated by the kernel splat showing the issue during Bluetooth driver initialization on an i.MX28 platform.
The technical root cause of this vulnerability stems from insufficient synchronization around the CTS state modification operations within the mxs-auart driver implementation. When the Bluetooth driver attempts to initialize and manage serial communication through the uart_handle_cts_change() function, it does not properly acquire the required uport->lock, creating a scenario where concurrent access can result in inconsistent state management. This race condition directly violates the expected locking semantics defined in the serial_core subsystem, where proper mutex acquisition is mandatory before modifying serial port state variables. The kernel warning indicates that the function is being called from mxs_auart_irq_handle, suggesting that interrupt context operations are not properly synchronized with other kernel threads that may be accessing the same serial port resources simultaneously. This pattern of improper locking represents a classic concurrency vulnerability that aligns with CWE-362, which specifically addresses concurrent execution using lock objects.
The operational impact of CVE-2024-27000 extends beyond simple system instability to potentially compromise the reliability of serial communication in embedded Linux systems. When the Bluetooth driver loads on affected i.MX28 boards, the race condition can lead to kernel oops, system crashes, or unpredictable behavior in serial data transmission. The vulnerability is particularly dangerous in industrial control systems, automotive applications, or IoT devices where reliable serial communication is critical for proper system operation. The issue affects systems using the Freescale MXS platform with mxs-auart serial drivers, making it relevant to a specific but significant class of embedded Linux deployments. From an ATT&CK perspective, this vulnerability could be leveraged for privilege escalation or denial-of-service attacks, as an attacker could potentially trigger the race condition to cause system instability or compromise serial communication channels that are essential for device operation.
Mitigation strategies for CVE-2024-27000 involve implementing proper spinlock protection around CTS state changes within the mxs-auart driver. The fix requires adding appropriate locking mechanisms before calling uart_handle_cts_change() to ensure that the uport->lock is held during CTS state modifications. This approach aligns with standard kernel development practices for concurrent access protection and follows the principle of least privilege in resource management. System administrators should update to kernel versions that include the patched serial_core implementation, which properly addresses the missing synchronization. Additionally, monitoring for kernel warnings related to serial communication and CTS handling can help identify systems vulnerable to this race condition. The fix demonstrates the importance of proper locking in kernel drivers and represents a corrective measure that addresses the fundamental concurrency issue rather than merely masking symptoms. Organizations using embedded systems with i.MX28 processors should prioritize this update to maintain system stability and prevent potential exploitation of the race condition for malicious purposes.