CVE-2026-98492 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net: macb: fix dma_alloc_coherent() leak on macb_alloc() error paths
Fix 3 leaks in macb_alloc() error paths: - Tx buffer allocated but crossing a 4G boundary: Tx leaked. - Rx buffer allocation fails: Tx leaked. - Rx buffer allocated but crossing a 4G boundary: Tx & Rx leaked.
This is because our error handling calls macb_free(bp) which in turn frees the buffers stored in bp->queues[0], but nothing has been stored
in there. Fix by storing allocated buffers into bp->queues[0] ASAP.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel network driver for MACB (Macbeth), commonly found on embedded systems and various ARM-based platforms, contained a resource management flaw within its buffer allocation routine known as macb_alloc(). This vulnerability manifests specifically during the initialization phase when the driver attempts to allocate DMA-coherent memory buffers required for transmitting and receiving network packets. The core issue stems from an improper sequencing of operations in the error handling logic. When allocating these critical data structures, the code would attempt to reserve Tx (transmit) and Rx (receive) buffer descriptors before fully committing them to the device's internal queue structure represented by bp->queues[0]. If any step in this multi-stage allocation process failed or encountered a boundary violation such as crossing a 4GB memory limit which is incompatible with certain DMA addressing modes, the error path would trigger. However, because the buffers had not yet been registered into the primary queue array at that moment, the subsequent cleanup function macb_free(bp) would attempt to free resources from an empty or uninitialized pointer location. This mismatch results in a classic resource leak where allocated kernel memory is never released back to the system pool upon failure.
From a technical perspective, this flaw represents a category of bugs often associated with improper error handling and state management during initialization sequences. The vulnerability allows for the gradual depletion of kernel DMA-coherent memory over time if the driver fails repeatedly or operates in an environment where allocation failures are frequent due to memory pressure or hardware constraints. While each individual leak might seem minor, repeated occurrences can lead to significant performance degradation as available contiguous physical memory diminishes. In severe cases, this exhaustion could prevent new network interfaces from initializing or cause existing ones to become unstable, effectively leading to a denial of service condition for the networking subsystem on that specific device. The issue is particularly relevant in embedded environments where DMA capabilities are often constrained by hardware architecture and 32-bit addressing limits, making the crossing of the 4GB boundary a plausible failure scenario during buffer allocation.
The operational impact of this vulnerability extends beyond simple memory waste. Network drivers operate at a low level within the kernel stack, and resource leaks here can have cascading effects on system stability. For systems relying on MACB for critical connectivity, such as industrial control systems or IoT devices, the inability to properly reclaim resources after allocation failures could lead to unpredictable behavior during high-load scenarios or when attempting to recover from transient network errors. Furthermore, because DMA buffers are mapped directly into physical memory with specific caching attributes, leaking them not only consumes virtual address space but also ties up physical pages that cannot be easily reclaimed by other subsystems until the driver is unloaded and reloaded, which may require a system reboot in some configurations.
To mitigate this vulnerability, the primary remediation involves correcting the order of operations within the macb_alloc() function to ensure that allocated buffers are immediately associated with their respective queue structures before any further allocation steps occur. By storing the Tx and Rx buffer pointers into bp->queues[0] as soon as they are successfully allocated, the error handling path can correctly identify and free these resources if subsequent allocations fail or boundary checks do not pass. This ensures that macb_free(bp) always operates on valid, registered data structures rather than uninitialized memory regions. System administrators should ensure their kernels are updated to include this patch, particularly for devices utilizing MACB Ethernet controllers where stable network connectivity is essential. Regular monitoring of kernel logs for allocation failures can also help identify systems potentially affected by similar resource management issues in other drivers.
This type of vulnerability aligns with CWE-401 which describes a missing release of memory after effective usage, specifically highlighting the failure to free allocated resources upon error conditions. It also relates to CWE-755 related to improper handling of unusual or unexpected input if one considers allocation failures as exceptional inputs that trigger alternative code paths incorrectly implemented. In terms of attack vectors and detection, this falls under ATT&CK technique T1496 which involves resource hijacking through denial of service by exhausting system resources like memory. Although typically not exploitable for remote code execution due to the nature of kernel initialization routines being local or hardware-triggered rather than user-controlled input streams, it remains a significant reliability and stability concern that must be addressed in secure software development practices for embedded Linux environments.