CVE-2026-99029 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
net: sparx5: free the matchall entry on destroy
sparx5_tc_matchall_replace() allocates a struct sparx5_mall_entry for every offloaded matchall filter and adds it to sparx5->mall_entries. sparx5_tc_matchall_destroy() removes the entry from the list, but never frees it, so the entry of every deleted mirror and goto matchall filter is leaked.
Free the entry after unlinking it.
The leak was discovered by an AI code review agent, and reproduced with kmemleak on a lan969x EV board (EV23X71A) by repeatedly adding and deleting matchall mirror and goto filters. With the fix, kmemleak no longer reports the leak.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel networking subsystem for Microchip Sparx5 switches contains a memory management flaw within the traffic control offloading logic specifically affecting matchall filter operations. This vulnerability manifests as a resource leak where dynamically allocated kernel structures are not properly released upon deletion, leading to gradual consumption of system memory over time. The issue resides in the interaction between the function responsible for replacing or adding new filters and the function tasked with destroying existing ones within the sparx5_tc_matchall module. When a matchall filter is offloaded to hardware via sparx5_tc_matchall_replace, the kernel allocates a struct sparx5_mall_entry object to track metadata associated with that specific filter configuration. This structure is subsequently added to a global list maintained by the device driver instance to keep track of active offloaded entries for management and cleanup purposes during system shutdown or module unloading.
The core technical flaw occurs in the sparx5_tc_matchall_destroy function, which serves as the counterpart to the replacement operation when filters are removed from the traffic control configuration. While this destroy routine correctly removes the pointer to the entry structure from the internal list of active entries, it fails to invoke the appropriate memory deallocation routines for the struct sparx5_mall_entry itself. Consequently, although the reference is severed and the entry is no longer accessible through normal operational paths, the underlying memory block remains allocated in kernel space. This constitutes a classic use-after-free precursor or simply an unmanaged resource leak depending on how subsequent operations might interact with stale pointers, though in this specific case it primarily results in persistent memory retention that grows linearly with each add-and-delete cycle of mirror and goto matchall filters.
The operational impact of this vulnerability is characterized by progressive kernel memory exhaustion under sustained network configuration changes. In environments where traffic control rules are frequently updated, such as dynamic load balancing scenarios or automated policy enforcement systems utilizing Sparx5 hardware acceleration, the repeated allocation without corresponding deallocation leads to a steady increase in non-slub cache usage. Over time, this can degrade system performance due to increased pressure on the kernel memory allocator and potentially lead to out-of-memory conditions if left unmitigated. The vulnerability was identified through automated static analysis tools combined with dynamic runtime verification using kmemleak, confirming that every invocation of sparx5_tc_matchall_destroy results in a leaked object instance. Testing performed on LAN969X evaluation boards demonstrated clear evidence of memory growth correlated directly with the number of filter modifications until the fix was applied.
From a classification perspective, this vulnerability aligns with CWE-401 which describes missing release of memory after effective usage, indicating an improper cleanup procedure in software lifecycle management. It also relates to CWE-772 regarding missing release of resource after effective ownership, as the driver assumes responsibility for freeing allocated structures but neglects that duty during teardown operations. In terms of adversarial behavior mapping, this type of vulnerability can be leveraged within ATT&CK technique T1496 Resource Hijacking where an attacker might intentionally trigger repeated filter additions and deletions to exhaust system resources, thereby causing denial of service conditions without necessarily exploiting a code execution flaw. The lack of proper memory management creates a vector for resource starvation attacks against network infrastructure relying on this hardware offloading capability.
The remediation strategy involves modifying the sparx5_tc_matchall_destroy function to explicitly free the allocated struct sparx5_mall_entry after it has been unlinked from the active list. This ensures that the kernel's memory allocator can reclaim the space previously occupied by the filter metadata, restoring balance between allocation and deallocation operations. Developers must ensure that all code paths leading to entry removal include the necessary kfree or equivalent cleanup calls corresponding to the initial kzalloc or kmalloc invocations in the replacement routine. Verification of this fix requires rigorous testing using memory debugging tools like kmemleak under high-frequency filter modification workloads to confirm zero residual leaks are reported post-destruction events, thereby ensuring long-term stability for production deployments utilizing Sparx5 switch chipsets.