CVE-2026-74654: serial: 8250_dma: Clear stale RX state on shutdown
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250dma: Clear stale RX state on shutdown
serial8250releasedma() terminates RX DMA and releases the channel, but leaves rxrunning set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open.
The DesignWare BUSY workaround added by commit a7b9ce39fbe4 ("serial: 8250dw: Ensure BUSY is deasserted") calls serial8250rxdmaflush() from the LCR write path during startup. This happens before serial8250requestdma() obtains a new RX channel. On reopen, the stale rxrunning state therefore makes the flush path pass a NULL channel to dmaenginepause(), causing a kernel Oops.
Clear rxrunning after terminating RX DMA, matching the TX cleanup. Also make the flush helper return if the DMA object or RX channel is not available so startup and teardown paths cannot pass a NULL channel to the DMAengine API.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
What conditions are required to trigger the kernel Oops?
The affected serial port must use RX DMA, be closed while an RX DMA transfer is active, and then be reopened. During startup, the DesignWare BUSY workaround must invoke the RX DMA flush path before a new RX DMA channel is obtained.
Is this reachable without an external attacker?
Yes. The described failure is a local lifecycle issue triggered by closing and reopening an affected serial port while RX DMA is active. The provided information does not describe any network or remote attack path.
What is the impact when the issue is triggered?
The stale rx_running state can cause serial8250_rx_dma_flush() to pass a NULL RX DMA channel to dmaengine_pause(), resulting in a kernel Oops.
What mitigation is available if the fix cannot be applied immediately?
The provided data does not specify a configuration workaround. Avoiding close-and-reopen cycles of affected RX-DMA serial ports while an RX transfer is active would avoid the described trigger condition.