CVE-2026-22979: Linux Kernel Memory Leak Vulnerability

CVE-2026-22979 Overview

A memory leak vulnerability has been identified in the Linux kernel's networking subsystem, specifically in the skb_segment_list() function used during packet forwarding. This vulnerability affects the handling of packets aggregated by the Generic Receive Offload (GRO) engine, resulting in incorrect socket memory accounting that prevents proper socket destruction and leads to persistent memory leaks.

The vulnerability stems from a logic inconsistency introduced after commit ed4cccef64c1 ("gro: fix ownership transfer"), which changed how fraglist entries handle socket references. While fragments were updated to be explicitly orphaned (skb->sk = NULL), the corresponding memory accounting logic in skb_segment_list() was never adjusted. This mismatch causes sk_wmem_alloc to remain non-zero when the head SKB is freed, preventing socket destruction.

Critical Impact

Persistent memory leak in Linux kernel networking stack can lead to resource exhaustion and denial of service conditions on affected systems handling GRO packets.

Affected Products

• Linux Kernel (multiple versions with GRO packet handling)
• Systems utilizing SKB_GSO_FRAGLIST packets constructed by GRO
• Network infrastructure running affected kernel versions

Discovery Timeline

• 2026-01-23 - CVE CVE-2026-22979 published to NVD
• 2026-01-26 - Last updated in NVD database

Technical Details for CVE-2026-22979

Vulnerability Analysis

The memory leak occurs in the kernel's socket buffer (SKB) segmentation logic. When skb_segment_list() processes packets during forwarding operations, it handles SKBs that were aggregated by the GRO engine. The function is designed to manage memory accounting by transferring truesize from a parent SKB to newly created segments.

Prior to the problematic commit, the truesize subtraction was valid because fragments maintained a reference to the original socket. However, the ownership transfer fix changed this behavior by orphaning fraglist entries (setting skb->sk to NULL) to prevent illegal orphaning later in the networking stack. This meant the entire socket memory charge remained with the head SKB, but the accounting logic continued to subtract truesize for each fragment.

The result is an under-count of memory when the head is freed, which can be observed through KMEMLEAK when tearing down networking environments. The leak manifests as unreferenced objects remaining in memory with backtraces pointing to socket allocation functions like sk_prot_alloc, sk_alloc, and inet6_create.

Root Cause

The root cause is a logic mismatch between socket ownership handling and memory accounting in the GRO packet segmentation path. When commit ed4cccef64c1 changed fraglist entries to be orphaned, it disrupted the assumption that fragments carry socket references. The skb_segment_list() function unconditionally adds each fragment's truesize to delta_truesize and subtracts it from the parent SKB, but since fragments are no longer charged to the socket, this subtraction creates a persistent accounting error.

Attack Vector

This vulnerability is primarily a denial of service vector through resource exhaustion. While the exact attack vector complexity is unknown, an attacker with the ability to generate or route GRO-aggregated packets through an affected system could potentially trigger the memory leak condition.

The vulnerability affects the skb_segment_list() function which is exclusively used for SKB_GSO_FRAGLIST packets constructed by the GRO engine. The memory accounting error prevents proper cleanup of socket structures, leading to accumulation of unreferenced memory objects over time.

Exploitation would involve sustained network traffic that triggers the GRO aggregation and subsequent segmentation paths, causing gradual memory exhaustion on the target system.

Detection Methods for CVE-2026-22979

Indicators of Compromise

• KMEMLEAK reports showing unreferenced socket objects with backtraces to sk_prot_alloc, sk_alloc, or inet6_create
• Gradual increase in kernel memory usage without corresponding process memory growth
• Socket structures remaining in memory after network connections are terminated
• Non-zero sk_wmem_alloc values for sockets that should have been destroyed

Detection Strategies

• Enable KMEMLEAK in kernel debugging configurations to detect unreferenced memory objects
• Monitor /proc/slabinfo for unusual growth in socket-related slab caches
• Use ss or netstat to identify socket resource leaks over time
• Implement kernel memory monitoring tools to track socket allocation patterns

Monitoring Recommendations

• Set up alerts for sustained memory growth in kernel network subsystems
• Monitor for KMEMLEAK warnings in kernel logs (dmesg)
• Track socket creation and destruction rates to identify imbalances
• Implement automated testing of GRO packet handling in network environments

How to Mitigate CVE-2026-22979

Immediate Actions Required

• Update to a patched Linux kernel version containing the fix
• If immediate patching is not possible, consider disabling GRO on affected interfaces as a temporary workaround
• Monitor system memory usage closely for signs of resource exhaustion
• Plan maintenance windows for kernel updates on production systems

Patch Information

The fix removes the unnecessary truesize adjustment in skb_segment_list() since this function is exclusively used for SKB_GSO_FRAGLIST packets constructed by GRO. The patch preserves the call to skb_release_head_state() as it is still required to correctly drop references to SKB extensions that may be overwritten during __copy_skb_header().

Multiple kernel stable branch commits have been published to address this vulnerability:

• Kernel Git Commit 0b27828e
• Kernel Git Commit 238e03d0
• Kernel Git Commit 32648814
• Kernel Git Commit 88bea149
• Kernel Git Commit c114a32a

Workarounds

• Temporarily disable GRO on network interfaces using ethtool -K <interface> gro off
• Implement memory monitoring to detect and alert on potential leak conditions
• Schedule regular system reboots for critical systems where immediate patching is not feasible
• Consider network traffic shaping to reduce GRO packet processing load

# Temporarily disable GRO on affected interface
ethtool -K eth0 gro off

# Verify GRO is disabled
ethtool -k eth0 | grep generic-receive-offload

# Monitor kernel memory for leak detection
cat /proc/meminfo | grep -E "Slab|SReclaimable|SUnreclaim"

# Enable KMEMLEAK for debugging (requires kernel config)
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak