Cloudanix VulnDB

CVE-2026-99029

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A small memory leak in certain network switch drivers can slowly use up system memory when network filter rules are added and removed, potentially making the device slower or unstable over time.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Failure to free a dynamically allocated struct sparx5_mall_entry after it is removed from the mall_entries list during matchall filter destruction, causing a kernel memory leak on every deletion of mirror or goto filters.

Why it matters to the business

On systems using the affected Sparx5 network hardware, repeated addition and deletion of matchall filters can slowly exhaust kernel memory, eventually causing performance degradation, allocation failures, or system instability; the issue was introduced recently and remains unfixed in mainline.

How an attack unfolds

An attacker with sufficient privileges to install and remove tc matchall filters on a Sparx5-based device repeatedly triggers the allocation path without the corresponding free, gradually leaking memory until the system is impaired; no remote unauthenticated path exists and no named threat actors have been observed exploiting it.

How to fix it

Apply the upstream fix that calls kfree on the mall_entry after unlinking it from the list; rebuild and deploy the corrected kernel image for any distribution or custom build that includes the sparx5 driver.

How to confirm the fix worked

Inspect the sparx5_tc_matchall_destroy function in the kernel source to confirm the kfree call is present after list removal; reproduce the original leak scenario with kmemleak enabled and verify no new reports appear after repeated filter operations.

Typical attack path

  1. Obtain local or administrative access to a host with a Sparx5 switch device
  2. Use tc to install a matchall filter of type mirror or goto
  3. Delete the filter, causing the entry to be unlinked without being freed
  4. Repeat the add/delete cycle to accumulate leaked kernel memory
  5. Continue until memory pressure leads to denial of service or system crash

How to detect it

Monitor kernel logs for repeated sparx5 mall entry allocations without corresponding frees; on development or test hardware, run kmemleak scans after filter churn to observe unreclaimed objects; no widespread exploitation indicators have been published.

What your security team should do

  • Prioritize patching kernel packages containing the sparx5 driver on all affected devices within the next maintenance window
  • Limit use of tc matchall filters on Sparx5 hardware until the fix is deployed
  • Enable kmemleak or similar kernel memory debugging on test systems to monitor for the leak
  • Review tc filter usage in automation scripts to reduce unnecessary add/delete churn

The record

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.

Affected packages

Ecosystem Package Introduced Fixed