CVE-2024-27000 - Linux Kernel **serial: mxs-auart** Race Condition

The Linux kernel, which powers most of our servers, laptops, and devices, is constantly being improved to make it faster, more reliable, and secure. Sometimes, however, bugs slip through that can cause system instability or, in the worst cases, create security risks.

Recently, a vulnerability tracked as CVE-2024-27000 was fixed in the Linux kernel’s serial subsystem, particularly affecting the mxs-auart driver. This post explains what went wrong, how it was fixed, and what it could mean for you. No fluff, just a clear breakdown with real-world details and code.

What is the mxs-auart Driver?

The mxs-auart driver provides serial port support for certain Freescale (now NXP) chips, such as the i.MX28. Serial ports are important for logging, hardware debugging, and connecting peripherals, including Bluetooth chips via UART (Universal Asynchronous Receiver/Transmitter).

What Was the Vulnerability?

The bug involved a lack of proper locking (specifically, missing spinlock protection) when changing the CTS (Clear To Send) state in the serial subsystem. This mistake meant the Linux kernel could experience a race condition, leading to strange, hard-to-diagnose errors—like warnings, kernel crashes, or potentially even memory corruption.

Technical deep-dive:
The uart_handle_cts_change() function in the kernel’s serial_core code expects that the caller holds a certain lock (uport->lock). Without this, two things could try to change the state at once, causing unpredictable results.

Typical Crash Output

[   85.119255] ------------[ cut here ]------------
[   85.124413] WARNING: CPU:  PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+xb4/xec
[   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[   85.143314] CPU:  PID: 27 Comm: kworker/u3: Not tainted 6.6.3-00021-gd62a2f068f92 #1
[   85.151396] Hardware name: Freescale MXS (Device Tree)
[   85.156679] Workqueue: hci hci_power_on [bluetooth]
...
[   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+x380/x3f4
[   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+x88/x210
...

If your logs look like this after plugging in or powering on a Bluetooth device, you may have hit this bug.

The Root Cause: A Missing Spinlock

Inside the mxs_auart_irq_handle() routine, the code was calling uart_handle_cts_change() without first acquiring the expected lock:

// Vulnerable snippet (simplified)
if (condition) {
    uart_handle_cts_change(&s->port, cts);
}

According to the kernel documentation and code conventions, this is unsafe. Multiple kernel threads could change UART state at once, leading to a *race*.

The Fix: Lock It Down

The upstream Linux kernel patch (see the commit) added a spinlock to ensure that only one thread can mess with the port at a time.

// Safe, patched version.
spin_lock(&s->port.lock);
uart_handle_cts_change(&s->port, cts);
spin_unlock(&s->port.lock);

*This ensures the port’s state isn’t changed by two places at the same time.*

Can This Be Exploited?

So far, there's no direct privilege escalation or data leak known for CVE-2024-27000 — but kernel race bugs in hardware drivers are known to have the potential for denial of service (DoS) (crashes) and, in some cases, attackers can chain them with other bugs for more serious exploits.

Who is vulnerable?

- Users on i.MX28 or other Freescale/NXP chips using mxs-auart.

Update your kernel: Use at least Linux 6.7, or find your vendor’s backport.

2. Check your distribution: Some distros have already rolled out fixes. See the Linux stable release note.

If you build your own kernels, cherry-pick or backport this commit:

serial: mxs-auart: add spinlock around changing cts state

References & Original Sources

- Kernel.org patch commit
- Linux Kernel Mailing List (LKML) patch discussion
- Serial Core: CTS flow control in the Linux kernel

Conclusion

CVE-2024-27000 is a reminder that even old-school hardware drivers need modern scrutiny. If you rely on serial-connected devices—or just want a stable system—keep your kernel up-to-date, and don't ignore those weird serial port kernel warnings. Behind the scenes, a simple spinlock can be the difference between a rock-solid device and endless debugging headaches.

Stay patched, stay smart.

*If you found this helpful or have questions about updating your kernel for this issue, feel free to ask below.*

Timeline

Published on: 05/01/2024 06:15:18 UTC
Last modified on: 05/04/2025 09:01:51 UTC