CVE-2026-74654: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-74654 Overview

CVE-2026-74654 is a null pointer dereference vulnerability in the Linux kernel's 8250_dma serial driver. The flaw stems from serial8250_release_dma() terminating RX DMA and releasing the channel, but leaving the rx_running state flag set. If a port closes while an RX transfer is active, the stale state persists while rxchan is NULL until the channel is requested again on the next open. The DesignWare BUSY workaround introduced by commit a7b9ce39fbe4 calls serial8250_rx_dma_flush() from the LCR write path during startup, which passes a NULL channel to dmaengine_pause() and triggers a kernel Oops.

Critical Impact
Local trigger paths that reopen an 8250 serial port with an active DesignWare-based UART can cause a kernel Oops, resulting in a denial-of-service condition on the affected system.

Affected Products

Linux kernel serial: 8250_dma driver
Systems using 8250_dw DesignWare UART controllers with DMA
Kernel branches receiving stable backports referenced in the fix commits

Discovery Timeline

2026-08-22 - CVE-2026-74654 published to NVD
2026-08-22 - Last updated in NVD database

Technical Details for CVE-2026-74654

Vulnerability Analysis

The vulnerability lives in the interaction between the 8250 UART DMA teardown path and the DesignWare BUSY workaround. When serial8250_release_dma() runs during port shutdown, it terminates the active RX DMA transfer and releases rxchan, but never clears the rx_running flag on the UART DMA state. The driver is left inconsistent: rx_running claims a transfer is in progress, while rxchan is NULL.

On the following port open, serial8250_do_startup() writes to the Line Control Register (LCR). The DesignWare workaround intercepts that write and calls serial8250_rx_dma_flush() before serial8250_request_dma() has allocated a new channel. Because rx_running is still set from the previous session, the flush helper proceeds into dmaengine_pause() with a NULL channel pointer, and the kernel Oopses.

Root Cause

The root cause is missing state cleanup on shutdown. The TX path clears its equivalent running flag, but the RX release path does not, producing a stale flag that survives across the DMA channel lifetime. This is a null pointer dereference [CWE-476] driven by an inconsistent driver state machine.

Attack Vector

The fault requires local interaction with an affected serial port on hardware using the DesignWare 8250 variant with DMA. An unprivileged user or process that can open, use, and close such a serial device may trigger the reopen sequence that dereferences the null channel. There is no evidence of remote exploitation, and no public exploit is available. The EPSS probability sits at 0.177%.

See the Linux kernel fix commits for the exact code paths modified. The fix clears rx_running after terminating RX DMA and adds a guard so serial8250_rx_dma_flush() returns early when the DMA object or RX channel is unavailable.

Detection Methods for CVE-2026-74654

Indicators of Compromise

Kernel Oops entries in dmesg or journalctl -k referencing dmaengine_pause, serial8250_rx_dma_flush, or 8250_dw during serial port open operations.
Repeated crashes correlated with processes that open and close /dev/ttyS* devices backed by DesignWare UART controllers.
Unexpected loss of serial console availability following userspace serial port activity.

Detection Strategies

Monitor kernel logs for null pointer dereference traces whose call stack includes serial8250_do_startup followed by serial8250_rx_dma_flush.
Inventory hosts running vulnerable kernel versions on hardware that uses the 8250_dw driver, such as many Intel SoC and embedded platforms.
Correlate serial device open events with subsequent kernel panics or soft lockups to distinguish this bug from unrelated DMA errors.

Monitoring Recommendations

Forward kernel ring buffer messages to a centralized log platform and alert on Oops or BUG: entries citing 8250 symbols.
Track kernel version and vendor patch level across the fleet to identify unpatched systems using DesignWare UART hardware.
Baseline normal serial subsystem activity so anomalous open/close bursts against ttyS* devices surface quickly.

How to Mitigate CVE-2026-74654

Immediate Actions Required

Apply the upstream Linux kernel patches that clear rx_running in serial8250_release_dma() and guard serial8250_rx_dma_flush() against a NULL DMA channel.
Update to a distribution kernel that includes the referenced stable backports for the 8250_dma fix.
Restrict access to serial device nodes so only trusted service accounts can open /dev/ttyS* interfaces on affected hardware.

Patch Information

The fix is committed across multiple Linux stable branches. Reference commits include 9f2444f4c0e4, ae05d9e50b6b, bf4fb620e029, d06cfb1add4a, e10f06ee050a, e2fe6a0efecb, e7a5d792cf64, and e7e3cc6709ca. See the Linux kernel stable tree for the canonical change. The patch clears the stale rx_running state after RX DMA termination, matching the existing TX cleanup, and makes the flush helper return early when the DMA object or RX channel is not available.

Workarounds

Disable DMA for the 8250 serial driver by booting with the 8250.dma_disable=1 or equivalent kernel parameter where the platform supports it.
Avoid workloads that repeatedly open and close DesignWare-backed serial ports on unpatched kernels until the fix is deployed.
Where feasible, unbind the 8250_dw driver from unused UART instances to shrink the attack surface.

bash

# Verify the running kernel and check for the fix in the changelog
uname -r
grep -R "8250_dma" /usr/share/doc/kernel-*/changelog* 2>/dev/null

# Restrict serial device access to a trusted group
chown root:dialout /dev/ttyS*
chmod 0660 /dev/ttyS*