CVE-2026-80886: serial: msm: Disable DMA for kernel console UART
In the Linux kernel, the following vulnerability has been resolved:
serial: msm: Disable DMA for kernel console UART
At the moment, concurrent writes from userspace and the kernel to the console can trigger a race condition that results in an infinite loop of the same messages printed over and over again. This is most likely to happen during system startup or shutdown when the init system starts/stops a large number of system services that interact with various kernel code.
When userspace writes to the TTY device, the driver initiates an asynchronous DMA transfer and releases the port lock. At the same moment, the kernel printk path might grab the port lock and re-configure the UART controller for PIO, without waiting for the DMA operation to complete. It seems like this collision results in zero progress being reported for the DMA engine, so the same text is printed to the console over and over again.
For the kernel console, we want a reliable output path that will be functional even during crashes etc. So rather than implementing complex code to synchronize the kernel console write routines with the userspace DMA write routines, simply disable DMA for the console UART instance.
Similar checks exist in many other serial drivers, e.g. 8250port.c, imx.c, sh-sci.c etc.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Disable DMA for the kernel console UART instance in the affected serial driver (described as: “Disable DMA for kernel console UART”).
Linux kernel serial: msm DMA for kernel console UART = disabled
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using an MSM serial UART as the kernel console are exposed when userspace can write to that UART's TTY device while the kernel is also producing console output. The condition is most likely during startup or shutdown, when many services interact with kernel code.
What must occur for the failure to be triggered?
A userspace TTY write must start an asynchronous DMA transfer, and the kernel printk path must concurrently reconfigure the same UART for PIO before that DMA operation completes. This race can cause the DMA engine to report zero progress.
How can I identify a potentially affected system?
Look for the same console messages being printed repeatedly in an apparent infinite loop, particularly during boot or shutdown. This behavior indicates the DMA/PIO collision described by the vulnerability.
What is the mitigation if the fix cannot be deployed immediately?
Disable DMA for the UART instance used as the kernel console. This avoids the unsynchronized DMA transfer path for console writes and preserves a reliable PIO-based console output path.