CVE-2026-53300: Linux Kernel ENETC Use-After-Free Flaw

CVE-2026-53300 Overview

CVE-2026-53300 is a use-after-free vulnerability in the Linux kernel's NXP ENETC (Enhanced Network Controller) driver, specifically in the NTMP (Network Table Management Protocol) command handling path. The flaw occurs when netc_xmit_ntmp_cmd() times out and returns an error without aborting the pending hardware command. The function ntmp_free_data_mem() then unconditionally frees the DMA buffer, allowing the hardware to later write response data to freed memory. This can result in silent memory corruption if the buffer has been reallocated for other kernel purposes.

Critical Impact
A local attacker with low privileges can trigger DMA writes to freed memory, leading to kernel memory corruption, potential privilege escalation, or denial of service.

Affected Products

Linux kernel builds including the net: enetc driver with NTMP command support
Systems using NXP ENETC network controllers (LS1028A, i.MX platforms)
Kernel versions prior to the commits referenced in the fix

Discovery Timeline

2026-06-26 - CVE-2026-53300 published to NVD
2026-06-30 - Last updated in NVD database

Technical Details for CVE-2026-53300

Vulnerability Analysis

The vulnerability resides in the ENETC driver's NTMP command submission logic. The driver submits commands to hardware through a command buffer descriptor ring (CBDR), passing DMA-mapped memory to the device for both request and response data. When netc_xmit_ntmp_cmd() times out, the function returns an error to the caller without instructing the hardware to abort the pending command.

The caller path then invokes ntmp_free_data_mem(), which unconditionally releases the DMA buffer via dma_free_coherent(). Because the hardware descriptor still references the physical address of that buffer, the device eventually completes the command and performs a DMA write to memory the kernel has already reclaimed. If the memory has been reallocated, the write silently corrupts unrelated kernel data structures.

A secondary race exists in the locking model. The original ring_lock was a spinlock and was released inside netc_xmit_ntmp_cmd() before the caller finished consuming the response buffer. A concurrent thread submitting a new command could invoke ntmp_clean_cbdr() and free the response buffer while the first caller was still reading it.

Root Cause

The root cause is improper DMA buffer lifecycle management combined with insufficient synchronization between the driver and the hardware. The driver assumed command completion or timeout meant the hardware had released its reference to the DMA buffer, but no explicit abort or cancellation protocol existed for timed-out commands. This is a classic Use-After-Free condition where the freeing party (the kernel) and the accessing party (the DMA-capable NIC hardware) operated on different lifetime assumptions.

Attack Vector

Exploitation requires local access and low privileges to trigger NTMP command paths in the ENETC driver, typically through network configuration operations. An attacker who can induce command timeouts, for example by generating device contention or workload pressure, may cause the driver to free DMA buffers while the hardware still holds references. Reliable exploitation would require heap spraying techniques to place attacker-controlled or security-sensitive data at the freed physical address before the delayed DMA write occurs.

Because netc_xmit_ntmp_cmd() executes without user-supplied code, exploitation is not straightforward. However, the resulting kernel memory corruption is deterministic once the timeout condition is triggered. Refer to the kernel commit 655d9ce9b1d3 for the complete fix implementation.

Detection Methods for CVE-2026-53300

Indicators of Compromise

Kernel log entries containing NTMP command timeout messages from the enetc driver
Unexpected SLUB or SLAB corruption reports on systems using ENETC network controllers
Sporadic kernel panics or KASAN use-after-free reports referencing ntmp_free_data_mem or netc_xmit_ntmp_cmd
Anomalous DMA errors reported by the IOMMU on affected NXP platforms

Detection Strategies

Enable CONFIG_KASAN on test kernels to catch DMA-related use-after-free conditions during QA cycles
Enable IOMMU protection where hardware supports it, so stray DMA writes generate faults rather than silent corruption
Audit installed kernel versions against the fixed commits 37c8933064be, 3cade698881e, and 655d9ce9b1d3 on affected distributions

Monitoring Recommendations

Collect and centrally analyze kernel ring buffer (dmesg) output for ENETC and DMA-related warnings
Monitor for unexpected reboots or kernel crashes on systems using NXP ENETC-based NICs
Track kernel package versions across the fleet to identify hosts running vulnerable driver code

How to Mitigate CVE-2026-53300

Immediate Actions Required

Apply the upstream kernel patches referenced in the fix commits to all affected systems
Prioritize patching on embedded and industrial devices using NXP ENETC hardware, where local access boundaries are often weaker
Restrict local access on multi-tenant systems until patches are deployed
Inventory all Linux systems using ENETC drivers and confirm patch status

Patch Information

The fix is implemented across three upstream commits: 37c8933064be, 3cade698881e, and 655d9ce9b1d3. The patches convert cbdr->ring_lock from a spinlock to a mutex, introduce a software shadow buffer descriptor (struct netc_swcbd) to track DMA buffer ownership independently of hardware writeback, and require callers to hold ring_lock across netc_xmit_ntmp_cmd() invocations. The helper functions ntmp_select_and_lock_cbdr() and ntmp_unlock_cbdr() were added to enforce the new locking discipline.

Workarounds

No functional workaround exists that preserves ENETC driver operation; patching is the only durable fix
Where patching is delayed, disable the ENETC interface if network connectivity can be provided through an alternate NIC
Enforce strict local-user access controls to reduce the attack surface until kernel updates are deployed

bash

# Verify installed kernel version and check for the fix
uname -r

# On Debian/Ubuntu systems, check kernel package version
apt list --installed 2>/dev/null | grep linux-image

# On RHEL/Fedora systems
rpm -qa | grep kernel

# Confirm ENETC driver is loaded
lsmod | grep enetc