CVE-2026-63857

What it actually does

This vulnerability is in the Linux kernel Airoha network driver transmit path, specifically airoha_dev_xmit(). During packet transmission, the driver can read fragment address and length data after the final valid skb fragment, meaning it accesses uninitialized fragment metadata. Although the incorrectly read values are not intended to be used for transmission, the unsafe read can trigger a kernel page fault. In practical terms, a reachable vulnerable system using the affected driver may experience a kernel crash, network disruption, or denial of service when processing crafted or edge-case transmit traffic. The accompanying fix also changes skb ownership handling so the socket buffer is freed only after the final transmit descriptor is processed, reducing the risk of premature cleanup during descriptor processing.

Why it matters to the business

Systems that rely on affected Linux kernels and Airoha network hardware may be vulnerable to crashes or loss of network availability. For routers, gateways, appliances, embedded Linux devices, or network-facing systems using this driver, exploitation could cause service interruptions, device reboots, degraded connectivity, or operational outages. Although this issue is not currently listed in CISA KEV and no public exploit maturity is reported, the high CVSS score and network-adjacent kernel impact justify prioritizing patching where the affected driver is present.

How an attack unfolds

An attacker would need to cause a vulnerable system using the Airoha network driver to process transmit traffic that exercises the buggy fragment-handling path in airoha_dev_xmit(). The vulnerable transmit loop iterates one step too far and reads fragment address and length metadata when the loop index equals the number of valid skb fragments. At that point, the fragment data is uninitialized. Depending on memory layout and runtime conditions, the unsafe read can trigger a kernel page fault. If the fault is not recoverable, the system may log a kernel oops or panic, interrupt packet transmission, reset the network interface, or crash the host/device. There is no indication from the provided data that active exploitation, ransomware use, or named threat actor exploitation has been observed.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Airoha driver transmit path. Because no specific affected product list or fixed package versions were provided, remediation should be based on the Linux distribution, appliance vendor, or kernel source tree in use. Prioritize systems that have Airoha network hardware, load the affected airoha driver, or run embedded/network appliance kernels derived from vulnerable upstream code. If immediate patching is not possible, reduce exposure by limiting untrusted network reachability to affected devices, disabling unused affected interfaces where operationally feasible, using an alternate network driver or kernel build that does not include the vulnerable code path, and increasing monitoring for kernel oops/panic events involving the Airoha driver.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the patch that prevents reading fragment metadata on the final airoha_dev_xmit() loop iteration and defers skb freeing until the final descriptor is processed. Validate the running kernel version against the distribution or vendor advisory rather than only checking installed package metadata, because systems may require a reboot to load the fixed kernel. On Linux systems, check the active kernel with uname -r, review loaded modules with lsmod, and inspect dmesg or journalctl for Airoha driver initialization. If source validation is possible, confirm that the airoha_dev_xmit() logic avoids reading fragment address and length when the loop index equals skb_shinfo(skb)->nr_frags. After patching and rebooting, perform normal network transmit testing and verify that no new kernel oops, page fault, skb, qdma, or airoha transmit errors appear in kernel logs.

Typical attack path

1. Identify a Linux-based system or appliance likely to use the Airoha network driver.
2. Send or induce network traffic patterns that cause the vulnerable device to transmit fragmented socket buffers through the affected driver path.
3. Trigger the airoha_dev_xmit() transmit loop condition where the loop index reaches skb_shinfo(skb)->nr_frags.
4. Cause the driver to read uninitialized fragment address or length metadata.
5. Induce a kernel page fault, oops, panic, interface failure, or device reboot, resulting in denial of service.

How to detect it

Detection should focus on evidence of attempted triggering or successful denial of service rather than traditional compromise artifacts, because the described flaw causes unsafe kernel memory access in a network driver and does not inherently create files, users, persistence, or command execution. Review kernel logs, system journals, crash dumps, pstore records, netconsole output, serial console logs, and appliance watchdog/reboot logs for oops, panic, page fault, or NULL/uninitialized memory access events involving airoha_dev_xmit(), airoha_qdma_tx_napi_poll(), the Airoha network driver, skb fragment handling, or QDMA transmit descriptors. Look for repeated crashes or interface resets correlated with bursts of network traffic, unusual packet sizes, fragmented/skb-heavy workloads, or remote connectivity attempts. For appliances, also review firmware event logs and uptime history for unexpected reboots. Because no known threat actors, KEV listing, or public exploit indicators are provided, detections should be behavior-based and centered on kernel fault telemetry and availability events.

• aiiroha_dev_xmit
• airoha_dev_xmit
• airoha_qdma_tx_napi_poll
• BUG: unable to handle page fault
• Unable to handle kernel paging request
• kernel NULL pointer dereference
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• skb_shinfo
• nr_frags
• NETDEV WATCHDOG
• qdma
• airoha
• page fault in airoha_dev_xmit
• Call Trace: airoha_dev_xmit
• Call Trace: airoha_qdma_tx_napi_poll

What your security team should do

• Inventory Linux systems, embedded devices, routers, gateways, and appliances that use Airoha network hardware or load Airoha kernel networking drivers.
• Prioritize patching or vendor firmware updates for internet-facing, branch-edge, appliance, or high-availability systems where network loss would cause operational disruption.
• Verify that patched kernels are actually running after maintenance windows; reboot systems where necessary.
• If fixed versions are not yet available from a vendor, request an advisory or backport status and apply compensating controls to reduce untrusted traffic exposure.
• Monitor kernel logs for page faults, oopses, panics, transmit failures, or qdma/airoha driver errors that may indicate attempted triggering or instability.
• Treat repeated unexplained crashes of affected network devices as potentially security-relevant, even if no public exploitation has been reported.
• Track upstream Linux kernel and distribution advisories for exact fixed versions and backport identifiers.