CVE-2026-53299

What it actually does

This flaw is a Linux kernel denial-of-service issue in the Airoha QDMA network driver transmit initialization path. If allocation of the queue entry list fails during TX queue setup, cleanup code can run while the queue entry array is still NULL because the descriptor count is initialized too early. The resulting NULL pointer dereference can trigger a kernel oops or panic, potentially crashing the system or disrupting networking on devices using the affected Airoha network hardware/driver path.

Why it matters to the business

Successful exploitation can cause affected Linux-based systems, appliances, routers, or embedded devices using the vulnerable Airoha network driver to crash or lose network availability. The currently reported exploitation maturity is none, EPSS is very low, and the issue is not listed in CISA KEV, so immediate internet-scale exploitation is not indicated; however, organizations with Airoha-based Linux networking devices should still prioritize routine kernel/vendor firmware updates because the impact is service disruption.

How an attack unfolds

An attacker’s practical path depends on whether they can influence driver initialization, reinitialization, or system memory pressure on a device using the vulnerable Airoha QDMA driver. The vulnerable condition occurs when TX queue initialization begins, the descriptor count is set before all related allocations are complete, and allocation of the queue entry list fails. Cleanup then assumes queue entries exist and dereferences a NULL pointer. In realistic scenarios, exploitation is more likely through local, privileged, or adjacent operational conditions that force network interface reset/reload while memory is constrained, rather than a simple unauthenticated remote packet exploit. The result is denial of service through kernel oops, panic, interface failure, or device reboot.

How to fix it

Update to a Linux kernel or vendor firmware build that includes the upstream fix moving descriptor count initialization to the end of the Airoha QDMA TX initialization routine. Because no exact affected product list or fixed package versions were provided, use the relevant Linux distribution, device vendor, appliance, or embedded firmware advisory to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by limiting untrusted administrative access, preventing untrusted users from triggering interface resets or module reloads, monitoring memory pressure on affected devices, and applying operational safeguards such as watchdog/redundancy for critical network appliances.

How to confirm the fix worked

Confirm whether the running kernel includes the corrected Airoha QDMA driver code or vendor backport. Validate by checking the installed kernel/firmware version against vendor advisories, reviewing kernel source or package changelogs for the Airoha QDMA TX initialization fix, and confirming that systems using Airoha network hardware have been rebooted into the patched kernel. Where feasible in a lab, test interface initialization and reset under constrained-memory conditions and confirm the system no longer produces NULL pointer dereference, oops, panic, or airoha_qdma cleanup crash messages.

Typical attack path

1. Identify a Linux-based device using the Airoha QDMA network driver or affected vendor kernel/firmware.
2. Gain an execution position or operational influence that can trigger network driver initialization, interface reset, module reload, or device reboot.
3. Induce or wait for memory allocation failure during TX queue initialization, such as under memory pressure or constrained embedded-device conditions.
4. Trigger the vulnerable cleanup path after partial queue initialization failure.
5. Cause a NULL pointer dereference in the kernel, resulting in kernel oops, panic, networking failure, or system reboot.

How to detect it

To determine whether this issue may already have been triggered, review kernel logs, persistent journal logs, crash dumps, appliance diagnostic bundles, serial console output, and watchdog reboot records for crashes involving the Airoha QDMA driver. Focus on messages shortly before unexpected reboots, interface resets, driver reloads, or network outages. Look for NULL pointer dereference, kernel oops, panic, or call traces referencing airoha_qdma_init_tx_queue, airoha_qdma_cleanup_tx_queue, or related Airoha network driver functions. Also correlate with memory pressure indicators such as allocation failures, out-of-memory warnings, or failed GFP allocations near the same timestamp. Because this vulnerability produces a crash condition rather than a durable compromise artifact, absence of logs after reboot may limit forensic confidence unless persistent logging or crash capture is enabled.

• airoha_qdma_cleanup_tx_queue
• airoha_qdma_init_tx_queue
• airoha_qdma_init_tx
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• Call Trace:
• allocation failure
• page allocation failure
• Out of memory
• airoha
• qdma

What your security team should do

• Inventory Linux systems, network appliances, routers, and embedded devices that use Airoha network hardware or the Airoha QDMA driver.
• Prioritize vendor kernel or firmware updates for affected devices during the next maintenance window, especially for systems providing critical network connectivity.
• Because exploitation is not known in the wild and EPSS is low, treat this as a reliability and availability patch unless affected devices are exposed to untrusted local users or frequent remote management actions.
• Restrict administrative interfaces and automation capable of resetting interfaces, reloading drivers, or rebooting affected network devices.
• Monitor kernel logs for NULL pointer dereference or oops events involving Airoha QDMA functions.
• Ensure HA pairs, failover paths, or spare devices are available for critical deployments until patched.
• Track downstream vendor advisories because embedded and appliance vendors may ship the fix on timelines independent of the upstream Linux kernel.