CVE-2026-53248

What it actually does

This is a Linux kernel use-after-free in the Airoha network driver metadata destination teardown path. The RX path can attach a non-reference-counted dst pointer to a socket buffer under RCU assumptions, but the teardown path frees that metadata object immediately with kfree() rather than waiting for an RCU grace period. If packet processing still references the metadata after teardown, the kernel may dereference freed memory, causing memory corruption, kernel panic, or potentially attacker-influenced code execution in kernel context under favorable heap-reuse conditions.

Why it matters to the business

Systems using affected Linux kernels with the Airoha network driver may be vulnerable to crashes or instability when network traffic races with driver/interface teardown. Although EPSS is currently low, the issue affects kernel-level networking code, so successful exploitation could disrupt network appliances, embedded devices, routers, or hosts using this driver. It is not currently listed in CISA KEV and no public exploit maturity is indicated, reducing immediate exploitation urgency, but kernel memory-corruption flaws should still be remediated during normal patch cycles or faster for internet-facing/network-critical devices.

How an attack unfolds

An attacker first identifies a system running an affected Linux kernel with the Airoha network driver active. They then generate network receive activity against the affected interface while attempting to cause, wait for, or combine with interface teardown events such as driver reset, interface down/up, device removal, module unload, or network reconfiguration. During the race, packets may retain non-refcounted references to metadata_dst while the driver frees that object immediately. If the freed memory is accessed before RCU readers finish, the kernel can crash or corrupt memory. Reliable exploitation beyond denial of service would require precise timing and heap manipulation, and there is currently no indication of public exploit code or known in-the-wild exploitation.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution, appliance vendor, or upstream stable branch that includes the fix replacing immediate metadata_dst_free() teardown with dst_release() so freeing is deferred safely through RCU. No exact package fixed versions were provided, so use vendor advisories and kernel changelogs to identify the first fixed release for each platform. If immediate patching is not possible, disable or unload the Airoha network driver where it is not required, move affected devices away from untrusted network exposure, avoid unnecessary interface resets or driver reloads, and schedule maintenance to patch network-critical systems promptly.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the Airoha driver and whether an Airoha-backed interface is active. Validate remediation by verifying the installed kernel package or source contains the fix for 'net: airoha: Fix use-after-free in metadata dst teardown' and that a reboot has loaded the patched kernel. On source-based systems, confirm airoha_metadata_dst_free() no longer frees metadata_dst directly with metadata_dst_free()/kfree() and instead releases it through dst_release(). Also review distribution or vendor security advisories to ensure the running kernel version is at or above the vendor-fixed release.

Typical attack path

1. Identify Linux systems, appliances, or embedded devices using an affected kernel and the Airoha network driver.
2. Confirm the vulnerable driver/interface is active and reachable over the network.
3. Send sustained or carefully timed traffic to the affected network interface to keep RX processing active.
4. Trigger or wait for driver/interface teardown, reset, link flap, reconfiguration, or module unload conditions.
5. Win the race where an skb still references metadata_dst after it has been freed.
6. Cause kernel memory corruption, commonly resulting in kernel oops, panic, reboot, or possible privilege/code execution if exploitation is highly controlled.

How to detect it

Look for evidence of kernel instability or memory-corruption events involving the Airoha network driver, especially around link flaps, interface resets, module unloads, reboots, or network configuration changes. Useful log sources include kernel ring buffer output, system journal, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, hypervisor reset events, network device logs, and appliance firmware logs. Search for KASAN use-after-free reports, kernel oops/panic messages, RCU warnings, dst/skb stack traces, and function names from the affected path such as airoha_metadata_dst_free(), metadata_dst_free(), skb_dst_set_noref(), and dst_release(). Because no public exploitation is known, findings will usually indicate attempted triggering, instability, or accidental race conditions rather than definitive compromise. Correlate suspicious crashes with bursts of inbound traffic, interface down/up operations, driver reloads, firmware resets, or unexpected reboots.

• airoha_metadata_dst_free
• metadata_dst_free
• skb_dst_set_noref
• dst_release
• BUG: KASAN: use-after-free
• use-after-free in airoha
• general protection fault
• Unable to handle kernel paging request
• kernel NULL pointer dereference
• kernel panic
• RCU detected stall
• Call Trace:
• airoha_eth
• airoha

What your security team should do

• Prioritize patching systems that use Airoha network hardware or vendor appliances derived from affected Linux kernels.
• Inventory kernels and loaded network drivers for Airoha driver usage before broad emergency response, because systems without this driver are unlikely to be exposed to this specific flaw.
• Monitor kernel logs for use-after-free, RCU, dst, skb, and Airoha-related crashes until patches are deployed.
• For high-availability network devices, test the patched kernel in staging and plan controlled reboots to ensure the fixed kernel is actually running.
• If patching is delayed, reduce exposure by disabling unused Airoha interfaces/drivers and limiting untrusted traffic to affected interfaces.
• Track vendor advisories because exact fixed package versions vary by distribution and appliance firmware.