CVE-2026-43061

What it actually does

This flaw is a local denial-of-service condition in the Linux kernel 8250 serial driver when transmit DMA is used. When a serial transmit DMA transaction is terminated, dmaengine_terminate_async() does not guarantee that the transmit-completion callback runs. Because the driver previously relied on that callback to clear the tx_running state, a canceled transaction could leave the driver permanently believing transmit DMA was still active. As a result, new serial transmit DMA operations are not scheduled, causing the affected serial port’s transmit path to deadlock. The impact is availability only; it does not provide code execution, privilege escalation, data disclosure, or data modification by itself.

Why it matters to the business

Systems that depend on 8250-compatible serial ports with DMA can lose serial output or serial communications after local triggering of the bug. This can affect serial consoles, embedded systems, industrial devices, modem or out-of-band management workflows, and other workloads where serial connectivity is operationally important. The CVSS score is moderate, EPSS is very low and flat over 30 days, there is no known public exploit maturity, and it is not listed in CISA KEV, so broad internet-scale exploitation is unlikely. However, organizations with critical serial-console or embedded Linux dependencies should treat the availability impact as higher priority because recovery may require driver reset, service interruption, or reboot.

How an attack unfolds

An attacker must already have local access to the system and sufficient permission to interact with an affected 8250 serial device using DMA-backed transmission. The attacker initiates serial transmit activity and causes the transmit DMA operation to be flushed, canceled, or otherwise terminated before normal completion. In vulnerable kernels, the DMA termination path may not invoke the completion callback, leaving the driver's internal tx_running flag set. Because the driver believes a transmit DMA transaction is still in progress, subsequent transmit requests are not scheduled. The practical result is a persistent transmit deadlock on the affected serial port until the port, driver, or system is reset. There is no evidence from the provided intelligence of active exploitation, ransomware use, or named threat actor activity.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the 8250 serial DMA fix for this issue. No exact fixed package versions were provided in the input, so remediation should be based on vendor security advisories and kernel changelogs for the affected distribution. The corrected behavior clears the driver's transmit-running state after terminating the DMA transaction while holding the UART port lock. Where immediate patching is not possible, reduce exposure by restricting local access to serial device nodes, limiting membership in groups that can access serial ports, avoiding untrusted workloads on systems that expose affected serial devices, and disabling or avoiding serial DMA for affected ports where the platform and vendor support doing so. For systems where serial connectivity is critical, schedule maintenance windows because kernel updates typically require a reboot.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-provided fixed build for this vulnerability. If source-level validation is used, verify the 8250 serial DMA transmit flush path clears the transmit-running state after DMA termination in the protected UART-port-lock context. Confirm that relevant systems either do not use affected 8250 serial DMA transmit functionality or have been updated. Review permissions on serial device nodes to ensure only trusted users and services can access them. In non-production testing, validate that repeated serial transmit, flush, close, and reopen operations do not leave the port unable to transmit. After patching, confirm the system is actually booted into the fixed kernel rather than only having the package installed.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with an 8250-compatible serial port using DMA for transmit operations.
2. Obtain permission to open or otherwise interact with the affected serial device, such as a ttyS-style device node.
3. Start serial transmit activity that uses the driver's DMA transmit path.
4. Trigger a flush, cancellation, close, reconfiguration, or other condition that terminates the DMA transaction before ordinary completion.
5. Cause dmaengine_terminate_async() to return without the transmit-completion callback clearing the driver's tx_running state.
6. Leave the serial driver's transmit path stuck so future serial output is not scheduled.
7. Maintain denial of serial transmit availability until the driver, port, or system is recovered.

How to detect it

There are no reliable, specific indicators of compromise for this vulnerability from the provided intelligence, and exploitation would look like local use of serial devices followed by a serial transmit hang. Detection should focus on operational symptoms and local activity correlation. Review kernel logs, system journals, and serial service logs for sudden serial transmit stalls, UART or DMA errors, serial console hangs, or services blocked while writing to serial devices. Correlate those symptoms with local user sessions, container workloads, or services that opened ttyS-style devices shortly before the outage. Audit shell history, process accounting, sudo logs, auditd records, and device access logs where available for unusual writes, configuration changes, closes, or repeated open/flush behavior against serial device nodes. Because this is an availability flaw with no known malware artifact, absence of logs does not prove absence of exploitation; recovery actions such as rebooting may also clear volatile evidence.

What your security team should do

• Prioritize patching on systems that rely on serial consoles, embedded serial links, industrial communications, modem connectivity, or out-of-band workflows.
• Apply vendor kernel updates that include the 8250 serial DMA fix, and reboot into the fixed kernel where required.
• Inventory Linux systems that expose 8250-compatible serial devices, especially systems with /dev/ttyS* access granted to non-administrative users or services.
• Restrict serial device access to trusted users and service accounts until patched.
• Where supported and operationally safe, disable transmit DMA for affected serial ports as a temporary mitigation.
• Monitor for unexplained serial transmit failures, serial console hangs, or repeated local interaction with serial devices by untrusted users.
• Treat this as normal-to-elevated operational patching priority rather than emergency internet-exposed response because EPSS is very low, no public exploit maturity is reported, and the issue is not in CISA KEV.