CVE-2026-68321

What it actually does

A memory leak occurs in the txgbe network driver because perfect FDIR filters added while the interface is down remain on the software list and are never freed; unregister_netdev skips ndo_stop when the device is down, bypassing txgbe_fdir_filter_exit in txgbe_close, and the list is not released from txgbe_remove.

Why it matters to the business

Environments that frequently load or remove the txgbe driver without bringing the interface up can experience gradual kernel memory exhaustion, leading to performance degradation or instability over repeated cycles; low EPSS and absence from KEV indicate limited immediate operational urgency.

How an attack unfolds

An attacker would need local or privileged access to repeatedly add FDIR filters while the interface remains down and then trigger driver removal, causing the allocated filter structures to accumulate without being freed until the system is rebooted or memory is exhausted.

How to fix it

Apply the upstream kernel fix that additionally frees the FDIR filter list inside txgbe_remove; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

Inspect the txgbe driver source to confirm txgbe_fdir_filter_exit or equivalent list freeing logic now executes from txgbe_remove; perform load/remove cycles with the interface down while monitoring slab or kmemleak statistics for leaks.

Typical attack path

1. Obtain sufficient privileges to manage network interfaces and driver state
2. Add perfect FDIR filters while the interface is administratively down
3. Trigger repeated driver removal without calling close
4. Observe progressive kernel memory consumption until resource limits are reached

How to detect it

Review kernel logs and memory profiling output for repeated allocations of FDIR filter structures during driver unload events without corresponding frees; correlate with txgbe module load/remove timestamps.

What your security team should do

• Prioritize patching systems that use the txgbe driver in automated or containerized environments where driver reload is common
• Include the patched kernel in the next maintenance window even though EPSS remains low
• Add kernel memory usage baselines for network drivers to existing monitoring