CVE-2026-63859

What it actually does

This is a Linux kernel network-driver flaw in the Airoha QDMA transmit cleanup path. The driver failed to fully reset transmit DMA descriptors and failed to synchronize the hardware TX DMA index with the CPU TX index when cleaning the TX queue. As a result, after interface teardown, reset, error recovery, or driver reinitialization, the NIC may treat stale TX ring entries as valid, potentially causing DMA operations against freed or invalid buffers, packet transmission corruption, network interface instability, kernel warnings, or a kernel crash. Based on the available information, there is no public exploit maturity, no CISA KEV listing, and no indication of active ransomware use.

Why it matters to the business

Organizations running Linux systems or embedded/network appliances that use affected Airoha Ethernet/QDMA hardware could experience network outages, device instability, or reboots if the vulnerable driver state is reached. The most likely operational consequence is denial of service for the affected network interface or host rather than confirmed data theft or remote code execution. Urgency is moderate to low based on the currently low EPSS score and lack of known exploitation, but kernel and appliance updates should still be applied during normal maintenance windows, especially for routers, gateways, access points, or edge devices where network availability is critical.

How an attack unfolds

An attacker would first need the target to be running a vulnerable Linux kernel with the Airoha network driver in use. The vulnerable condition is associated with TX queue cleanup, so exploitation would likely require causing or waiting for interface reset, driver restart, link flap, error recovery, device suspend/resume, or similar lifecycle events while TX descriptors are active. If stale descriptors remain in the QDMA TX ring, the NIC may continue operating on invalid descriptor state after cleanup. In a practical attack scenario, an adversary able to generate network load and induce network instability might attempt to increase the chance of TX timeout or reset conditions, then observe whether the device loses connectivity, crashes, or reboots. There is currently no evidence of a reliable public exploit or active exploitation campaign for this issue.

How to fix it

Update to a Linux kernel version or vendor appliance firmware that includes the upstream fix for the Airoha QDMA TX cleanup routine. If using a distribution kernel, apply the vendor-provided security or stable kernel update rather than manually patching where possible. If maintaining a custom kernel, backport the fix that resets TX DMA descriptors in airoha_qdma_cleanup_tx_queue() and sets TX_DMA_IDX to TX_CPU_IDX so the NIC is explicitly informed that the QDMA TX ring is empty. If immediate patching is not possible, reduce exposure by limiting untrusted network access to affected devices, avoiding unnecessary interface resets under load, monitoring for TX timeout conditions, and planning controlled reboots or maintenance for devices showing instability.

How to confirm the fix worked

Confirm whether the running kernel includes the Airoha QDMA TX cleanup fix from the relevant upstream stable branch or vendor advisory. Validate that the deployed kernel package or firmware build is newer than the vendor-fixed release. On custom kernels, inspect the Airoha driver source to verify that airoha_qdma_cleanup_tx_queue() resets TX descriptors and synchronizes TX_DMA_IDX with TX_CPU_IDX. Confirm affected hardware is present and the driver is loaded before prioritizing host-level remediation. After patching, perform controlled interface down/up, link flap, restart, and traffic-load tests while monitoring dmesg or kernel logs for TX timeout, DMA, watchdog, oops, or panic messages.

Typical attack path

1. Identify a Linux-based system, appliance, or embedded device using Airoha Ethernet/QDMA hardware and a vulnerable kernel build.
2. Generate sustained or malformed network activity to increase transmit queue churn, if the attacker has network reachability.
3. Attempt to induce driver lifecycle events such as link flaps, TX timeouts, interface resets, or error recovery conditions.
4. Trigger or wait for TX queue cleanup while descriptors may still contain stale DMA state.
5. Cause the NIC or kernel driver to reuse invalid TX ring state after cleanup.
6. Achieve denial of service symptoms such as packet loss, interface hang, kernel oops, kernel panic, or device reboot.

How to detect it

There are no known public indicators of compromise or campaign-specific artifacts for this vulnerability. To assess possible prior triggering, review kernel logs, persistent journal entries, appliance system logs, crash dumps, and monitoring data for affected devices around periods of network instability. Focus on messages involving the Airoha driver, QDMA, TX queue cleanup, transmit timeouts, NETDEV watchdog events, DMA API warnings, kernel oopses, kernel panics, unexpected interface resets, or unexplained reboots. Correlate these events with high outbound traffic, link flaps, interface down/up events, firmware reloads, suspend/resume cycles, or attacker-controlled network activity. Because these symptoms can also occur due to hardware faults or unrelated driver issues, treat them as leads for investigation rather than definitive proof of exploitation.

• airoha
• QDMA
• NETDEV WATCHDOG
• transmit queue timed out
• TX timeout
• DMA-API
• kernel BUG
• Oops
• kernel panic - not syncing

What your security team should do

• Inventory Linux systems, routers, gateways, access points, and embedded appliances that use Airoha Ethernet/QDMA hardware or load the Airoha network driver.
• Prioritize patching internet-facing or availability-critical network devices, even though known exploitation and EPSS risk are currently low.
• Apply the relevant vendor kernel or firmware update that includes the Airoha QDMA TX cleanup fix.
• For custom kernel users, backport and test the upstream driver patch rather than relying on compensating controls.
• Monitor kernel logs for interface hangs, TX timeouts, DMA warnings, oopses, and unexplained reboots on affected hardware.
• If devices are unstable before patching, schedule controlled maintenance reboots and reduce untrusted traffic exposure where practical.
• Track vendor advisories because affected product lists and fixed package versions may vary across distributions and appliance firmware lines.