CVE-2026-53338

What it actually does

This is a local denial-of-service flaw in the Linux kernel Airoha networking driver. During Airoha QDMA hardware-forwarding queue initialization, the driver calls of_reserved_mem_lookup() for a device-tree memory-region reference and then dereferences the returned pointer without verifying that it is non-NULL. If the referenced reserved-memory entry is missing, malformed, or otherwise not present, the kernel can hit a NULL pointer dereference while reading rmem->base or rmem->size, causing an oops, panic, driver initialization failure, or system crash depending on kernel panic settings and platform configuration.

Why it matters to the business

Affected Linux systems using the Airoha networking driver can become unavailable if the vulnerable initialization path is reached with an invalid or missing reserved-memory configuration. The main risk is operational disruption on embedded, networking, router, gateway, or appliance platforms that rely on this driver. This issue is not listed in CISA KEV, has very low EPSS, and has no reported exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, organizations with affected hardware should still remediate during normal kernel maintenance because the outcome can be a full system outage.

How an attack unfolds

An attacker needs local influence over conditions that cause the vulnerable Airoha driver initialization path to execute with a missing or invalid device-tree reserved memory reference. In realistic scenarios, this may involve a user with sufficient local privileges to load, reload, bind, unbind, or trigger probing of the affected driver, or to introduce or boot a kernel/device-tree configuration where the memory-region phandle points to a reserved-memory node that is absent from the reserved memory table. When the driver initializes hardware-forwarding queues, of_reserved_mem_lookup() returns NULL. The vulnerable code then dereferences that NULL pointer while calculating DMA address or descriptor count, leading to a kernel NULL pointer dereference and potential crash. There is no indication from the supplied intelligence that this vulnerability is being exploited in the wild or used by ransomware campaigns.

How to fix it

Apply a Linux kernel update from the relevant distribution, hardware vendor, or stable kernel branch that includes the fix adding a NULL check after of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues() and returning -ENODEV when reserved memory lookup fails. No exact fixed version was provided in the input, so use vendor advisories, package changelogs, or upstream stable kernel notes to identify the first patched build for each distribution or appliance image. If immediate patching is not possible, mitigate by ensuring device-tree configurations for Airoha devices contain valid memory-region references and matching reserved-memory nodes, avoiding untrusted or ad hoc device-tree overlays, disabling or blacklisting the affected Airoha driver where it is not required, and limiting local administrative capabilities that allow driver reloads, module loading, or boot configuration changes.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or appliance firmware includes the Airoha driver patch for airoha_qdma_init_hfwd_queues(). Review vendor changelogs or source to confirm a NULL check exists after of_reserved_mem_lookup() and that failure returns -ENODEV before rmem->base or rmem->size is accessed. On affected platforms, validate that device-tree entries referencing memory-region for the Airoha device resolve to valid reserved-memory nodes. After patching or mitigation, reboot or reload according to vendor guidance and confirm the system no longer produces kernel oops or panic messages when the Airoha driver initializes. Also verify that unused affected drivers are not loaded if they have been disabled as a mitigation.

Typical attack path

1. Identify a Linux system running affected kernel code with the Airoha networking driver enabled and relevant Airoha hardware or device-tree configuration.
2. Gain local access with enough privileges to influence driver probing, module loading, device binding, reboot configuration, or device-tree/kernel configuration.
3. Create or trigger a condition where the device-tree memory-region reference exists but the corresponding reserved-memory lookup fails.
4. Cause the Airoha QDMA initialization path to run, such as through boot, device probe, driver reload, or device rebind.
5. The kernel dereferences a NULL reserved-memory pointer during queue initialization.
6. The system logs a kernel oops or panic and may crash, reboot, or lose networking availability.

How to detect it

To determine whether this was already triggered, review kernel logs and persistent journal data for oops, panic, call trace, or NULL pointer dereference events around Airoha driver initialization. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel records, crash dump directories, kdump/vmcore metadata, appliance support bundles, and remote syslog from embedded network devices. Look for call traces containing airoha_qdma_init_hfwd_queues, of_reserved_mem_lookup, airoha, qdma, reserved memory, or memory-region, especially followed by reboot, watchdog reset, interface loss, or kernel panic. Also inspect boot history for repeated crashes during driver probe and compare timestamps with administrative actions such as kernel upgrades, firmware changes, module reloads, driver rebinding, or device-tree overlay changes. There are no known threat actors or in-the-wild exploitation details in the supplied input, so detection should focus on local crash artifacts rather than network indicators.

• airoha_qdma_init_hfwd_queues
• of_reserved_mem_lookup
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• Call Trace:
• airoha
• qdma
• memory-region
• reserved-memory
• rmem->base
• rmem->size
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/device-tree
• /sys/firmware/devicetree/base

What your security team should do

• Inventory Linux systems, embedded appliances, routers, gateways, and network devices that use Airoha networking hardware or have the Airoha kernel driver enabled.
• Prioritize patching affected Airoha-based platforms during the next kernel or firmware maintenance window; accelerate for systems where local users can load drivers, change boot configuration, or apply device-tree overlays.
• Obtain patched kernels or firmware from the operating system distribution, device vendor, or appliance vendor, since no exact fixed versions were provided.
• Validate device-tree reserved-memory configuration for Airoha devices and correct missing or stale memory-region references.
• Disable or blacklist the affected Airoha driver on systems where it is not needed.
• Restrict local privileges that permit kernel module loading, driver unbinding/rebinding, firmware changes, bootloader edits, or device-tree overlay changes.
• Monitor kernel logs for NULL pointer dereference, oops, or panic events referencing airoha_qdma_init_hfwd_queues, of_reserved_mem_lookup, or Airoha QDMA initialization.
• Because this issue is not KEV-listed, not ransomware-associated in the supplied data, and has very low EPSS, treat it as availability-focused hardening unless affected devices provide critical network services.