CVE-2026-53247

What it actually does

This is a Linux kernel use-after-free in the MediaTek Ethernet SoC driver, mtk_eth_soc. During device teardown, the driver frees a metadata destination object immediately with kfree() while receive-path socket buffers may still hold non-refcounted references to that object under RCU semantics. If teardown occurs while packets are still being processed, kernel code can dereference freed memory. Depending on timing, memory reuse, kernel configuration, and attacker control over packet flow, the result may range from a kernel crash to potential kernel memory corruption. The issue is specific to systems using the affected MediaTek Ethernet driver path.

Why it matters to the business

Affected Linux systems using MediaTek Ethernet SoC networking may be exposed to network-triggered instability during interface, driver, or device teardown events. The most likely operational consequence is a kernel crash, watchdog reset, or loss of network availability on embedded, router, gateway, appliance, or IoT-style systems. Public exploitation maturity is currently listed as none, the EPSS score is low, and the issue is not in CISA KEV, so broad active exploitation is not indicated; however, kernel memory-safety flaws in network drivers should still be prioritized on exposed or remotely managed devices where downtime has business impact.

How an attack unfolds

An attacker would need to reach a system using the affected MediaTek Ethernet driver and influence packet reception while the network device is being torn down, reset, unloaded, reconfigured, or otherwise freed. The vulnerable condition occurs when received packets retain non-refcounted metadata destination pointers while the driver frees the backing object without waiting for an RCU grace period. A practical attack would attempt to create a race by sending traffic that exercises the RX path while also causing or waiting for interface teardown or reset conditions. If the race is won, kernel code may access freed memory. In realistic scenarios this is most likely to cause denial of service through a kernel crash or device reboot; reliable code execution would require additional primitives, precise heap manipulation, and target-specific kernel knowledge. No known public exploit or KEV-listed exploitation is indicated from the provided intelligence.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the fix replacing metadata_dst_free() with dst_release() in the MediaTek Ethernet driver teardown path. Because no exact fixed versions were provided, use distribution, appliance vendor, or kernel stable-tree advisories to identify the first patched release for the deployed kernel branch. Prioritize firmware and kernel updates for routers, gateways, embedded appliances, and internet-facing systems using MediaTek Ethernet SoCs. If immediate patching is not possible, reduce exposure by limiting untrusted network access to affected interfaces, avoiding unnecessary driver unload/reload or interface reset operations, disabling unused affected interfaces, and scheduling controlled maintenance windows for network reconfiguration.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or appliance firmware includes the upstream fix for the mtk_eth_soc metadata destination teardown path. Source-level validation can check that the affected teardown path uses dst_release() rather than metadata_dst_free() for this metadata destination object. Operational validation should include confirming the updated kernel is actually booted, not merely installed. On systems with kernel debugging available, stress-test interface resets or link cycling under network receive load and verify there are no kernel warnings, KASAN use-after-free reports, panics, or spontaneous reboots. Inventory validation should identify whether the mtk_eth_soc driver is present, loaded, or built into the running kernel on MediaTek-based systems.

Typical attack path

1. Identify a Linux-based device or appliance using a MediaTek Ethernet SoC interface handled by the mtk_eth_soc driver.
2. Send crafted or high-rate network traffic to keep the receive path active and create in-flight socket buffers using driver metadata.
3. Trigger, induce, or wait for a network device teardown condition such as interface reset, driver unload, link/device reset, configuration change, or error recovery.
4. Race the teardown path so metadata_dst is freed while RX-side RCU readers may still reference it.
5. Cause the kernel to dereference freed memory, potentially resulting in a crash, reboot, network outage, or memory corruption.

How to detect it

To assess prior exploitation or triggering, review kernel logs, persistent journal entries, serial console logs, appliance event logs, watchdog logs, and crash dumps for evidence of kernel use-after-free, NULL or invalid pointer dereferences, page faults, panics, or watchdog resets involving the mtk_eth_soc driver, metadata destination handling, RX processing, or network interface teardown. Correlate crashes with bursts of inbound network traffic, link flaps, interface resets, driver reloads, firmware network reconfiguration, or administrative actions such as bringing interfaces down. If KASAN, KFENCE, panic logs, vmcore, pstore, ramoops, or netconsole are enabled, search those artifacts for use-after-free reports referencing mtk_free_dev(), metadata_dst_free(), dst_release(), skb_dst_set_noref(), or mtk_eth_soc RX paths. Because this flaw is a kernel race condition and no public exploit indicators are provided, absence of a specific string does not prove absence of exploitation; focus on crash correlation and affected-driver evidence.

• mtk_eth_soc
• mtk_free_dev
• metadata_dst_free
• skb_dst_set_noref
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• Unable to handle kernel paging request
• kernel panic
• watchdog: watchdog0: watchdog did not stop
• NETDEV WATCHDOG
• Call Trace:
• metadata dst
• dst_release

What your security team should do

• Inventory Linux appliances, embedded systems, routers, gateways, and custom devices that use MediaTek Ethernet SoCs or load the mtk_eth_soc driver.
• Track vendor kernel or firmware advisories and apply the first release containing the mtk_eth_soc metadata destination teardown fix.
• Prioritize patching systems that are remotely reachable, handle untrusted network traffic, or have high availability requirements.
• Monitor affected devices for unexplained kernel panics, watchdog resets, link resets, interface teardown events, and RX-path kernel warnings.
• Avoid unnecessary network driver reloads, interface resets, or disruptive reconfiguration on potentially affected systems until patched.
• If patching is delayed, restrict untrusted traffic to affected interfaces and place vulnerable devices behind filtering or segmentation controls where feasible.
• Use kernel crash dumps, persistent journaling, and remote syslog on critical devices so evidence is retained after reboots.