CVE-2024-27000

What it actually does

Missing spinlock protection around CTS state changes in mxs-auart serial driver allows uart_handle_cts_change to be invoked without uport->lock held, triggering kernel warnings and potential race conditions during IRQ handling.

Why it matters to the business

Systems using affected Linux kernels on i.MX28 or similar hardware may experience kernel instability, warnings, or crashes during Bluetooth or serial operations, increasing downtime risk especially in embedded or industrial deployments with high prevalence of kernel dependents.

How an attack unfolds

An attacker with local access or ability to trigger serial/Bluetooth events loads a driver that exercises mxs_auart_irq_handle without proper locking, leading to the observed splat in uart_handle_cts_change; no public exploits known but race condition family allows potential for denial-of-service or escalation if combined with other flaws.

How to fix it

Update Linux kernel to commit 56434e295bd446142025913bfdf1587f5e1970ad or later stable version containing the spinlock addition around CTS state changes in drivers/tty/serial/mxs-auart.c.

How to confirm the fix worked

Verify kernel source contains the spinlock around uart_handle_cts_change calls in mxs_auart_irq_handle; test by loading hci_uart on i.MX28 hardware and confirming absence of the WARNING splat in dmesg.

Typical attack path

1. Identify system running vulnerable mxs-auart driver on supported hardware
2. Trigger Bluetooth power-on or serial CTS state changes via hci_uart or similar
3. Invoke IRQ path in mxs_auart_irq_handle without lock acquisition
4. Call uart_handle_cts_change concurrently to produce race and warning
5. Escalate to kernel panic or DoS if timing allows further corruption

How to detect it

Search kernel logs for the exact WARNING from serial_core.c:3453 uart_handle_cts_change and stack trace referencing mxs_auart_irq_handle; correlate with Bluetooth driver load events in dmesg or syslog on i.MX28 boards.

• WARNING: CPU:.* at .*serial_core.c:3453 uart_handle_cts_change
• mxs_auart_irq_handle from __handle_irq_event_percpu
• Workqueue: hci0 hci_power_on [bluetooth]
• Modules linked in: hci_uart bluetooth

What your security team should do

• Prioritize kernel upgrade to fixed commit 56434e295bd446142025913bfdf1587f5e1970ad within 30 days given 896 days since publication
• Monitor EPSS trend (stable at 0.0033) and apply patches to all embedded Linux distributions using mxs-auart
• Restrict untrusted local access on affected hardware until patched to reduce race triggering surface