CVE-2026-53298

What it actually does

This is a Linux kernel denial-of-service flaw in the Airoha Ethernet/QDMA driver initialization path. If allocation of RX queue entries or DMA descriptor lists fails during airoha_qdma_init_rx_queue(), cleanup logic may treat a partially initialized queue as fully initialized because the descriptor count is set too early. airoha_qdma_cleanup() can then call netif_napi_del() on an RX NAPI structure that was never registered with netif_napi_add(), causing a NULL pointer dereference and likely kernel oops or panic. The fix moves descriptor-count initialization until after successful queue setup and adjusts allocation ordering to avoid related memory leaks.

Why it matters to the business

Systems using affected Linux kernels with the Airoha networking driver may unexpectedly crash or reboot when the driver initialization path encounters allocation failures. In business terms, this can cause network appliance downtime, service interruption, packet forwarding disruption, and potential loss of availability for devices that depend on this Ethernet/QDMA driver. The CVE is not currently in CISA KEV, has no known ransomware association, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, embedded, router, gateway, or appliance fleets using this driver should still patch during normal kernel maintenance because availability failures in network devices can have outsized operational impact.

How an attack unfolds

An attacker would need a way to influence the affected driver initialization path and induce allocation failure or resource pressure at the right point during RX queue setup. In a realistic scenario, this is more likely to be triggered locally, through privileged device-management actions, repeated interface or driver reset cycles, or controlled memory pressure rather than through a simple unauthenticated network packet. Once the allocation failure occurs after the descriptor count has been set but before NAPI registration is complete, the kernel cleanup path runs. Because cleanup relies on the descriptor count as an initialization signal, it attempts to delete an unregistered NAPI object, leading to a NULL pointer dereference. The result is denial of service through kernel crash, oops, panic, or loss of networking on the affected device.

How to fix it

Apply the vendor-provided Linux kernel update that includes the corrected Airoha QDMA driver logic. Because no explicit affected product list or fixed package versions were provided, obtain the fixed kernel from the relevant Linux distribution, device vendor, SoC vendor, or appliance firmware provider and verify that the patch moving ndesc initialization to the end of successful RX queue initialization is present. For embedded or appliance deployments, update the complete firmware image if the kernel is not separately upgradeable. If immediate patching is not possible, reduce exposure by disabling unused Airoha network interfaces, avoiding unnecessary driver reload/reset operations, limiting administrative access to device-management functions, and monitoring for memory pressure or repeated interface initialization failures. Mitigations do not fully remove the flaw; kernel or firmware update is the durable fix.

How to confirm the fix worked

Confirm the running kernel or firmware build includes the upstream fix for the Airoha QDMA initialization issue. Validate by checking vendor advisories, kernel changelogs, package changelogs, or source diffs for changes in airoha_qdma_init_rx_queue() that move ndesc assignment until after successful queue/NAPI setup and reorder page_pool allocation after descriptor allocation. On deployed systems, confirm the updated kernel is actually running after reboot, not merely installed. Check whether the Airoha driver is present and loaded using standard kernel module, device tree, PCI/platform-device, or dmesg inspection. Review kernel logs after upgrade for absence of repeated airoha QDMA initialization failures, NULL pointer dereferences, kernel oopses, or panics involving netif_napi_del().

Typical attack path

1. Identify a Linux-based system or appliance using the affected Airoha Ethernet/QDMA kernel driver.
2. Obtain a way to trigger network driver initialization, reset, reload, or device bring-up paths, often requiring local or administrative access.
3. Create or wait for memory allocation pressure so RX queue or DMA descriptor allocation fails during airoha_qdma_init_rx_queue().
4. Trigger the affected initialization path while allocation failure occurs.
5. Cause airoha_qdma_cleanup() to run against a partially initialized RX queue.
6. Trigger a NULL pointer dereference in netif_napi_del(), causing kernel oops, panic, reboot, or network service interruption.

How to detect it

To determine whether this issue may already have been triggered, review kernel logs, persistent journal entries, serial console output, crash dumps, kdump/vmcore data, appliance support bundles, and firmware crash logs. Focus on events during boot, network interface bring-up, driver reset, module reload, or low-memory conditions. Look for kernel oops, panic, NULL pointer dereference, or call traces involving the Airoha QDMA driver and netif_napi_del(). Also review logs for preceding allocation failures in the same timeframe, such as DMA descriptor allocation failures, page_pool allocation failures, RX queue initialization errors, page allocation failures, or out-of-memory pressure. Because this vulnerability produces an availability failure rather than durable code execution, there may be no persistent attacker artifact beyond crash telemetry, reboot records, and related administrative actions that triggered interface or driver reinitialization.

• airoha_qdma_init_rx_queue
• airoha_qdma_cleanup
• netif_napi_del
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• page allocation failure
• DMA descriptor allocation failed
• page_pool allocation failed
• rx queue init failed
• Call Trace:
• airoha
• qdma

What your security team should do

• Prioritize patching Linux kernels or firmware images on systems that use Airoha Ethernet/QDMA networking hardware, especially routers, gateways, embedded appliances, and network edge devices where a crash affects availability.
• Inventory devices and kernel builds that include or load the Airoha networking driver; systems without this driver or hardware are unlikely to be exposed.
• Track distribution, appliance, and SoC vendor advisories because fixed versions may be delivered through downstream kernel or firmware packages rather than a generic upstream version number.
• Restrict access to administrative functions that can reset, reload, or reinitialize network drivers until patched.
• Monitor kernel logs and crash telemetry for NULL pointer dereferences, oopses, or panics involving airoha_qdma_cleanup(), airoha_qdma_init_rx_queue(), or netif_napi_del().
• Treat repeated unexplained crashes of affected network devices during interface initialization, firmware boot, or memory pressure as potential exploitation or fault-triggering events and preserve logs/crash dumps for analysis.