CVE-2026-22979
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-23

Last updated on: 2026-02-26

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: net: fix memory leak in skb_segment_list for GRO packets When skb_segment_list() is called during packet forwarding, it handles packets that were aggregated by the GRO engine. Historically, the segmentation logic in skb_segment_list assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments. Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), this truesize subtraction in skb_segment_list() was valid because fragments still carry a reference to the original socket. However, commit ed4cccef64c1 ("gro: fix ownership transfer") changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb->sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skb_segment_list() was never updated. As a result, the current code unconditionally adds each fragment's truesize to delta_truesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes sk_wmem_alloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak. The leak can be observed via KMEMLEAK when tearing down the networking environment: unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0 Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLIST packets constructed by GRO, the truesize adjustment is removed. The call to skb_release_head_state() must be preserved. As documented in commit cf673ed0e057 ("net: fix fraglist segmentation reference count leak"), it is still required to correctly drop references to SKB extensions that may be overwritten during __copy_skb_header().
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-23
Last Modified
2026-02-26
Generated
2026-05-07
AI Q&A
2026-01-23
EPSS Evaluated
2026-05-05
NVD
CVE-2026-22979
EUVD
EUVD-2026-4307
Affected Vendors & Products
Showing 16 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.9
linux linux_kernel 6.9
linux linux_kernel 6.9
linux linux_kernel 6.9
linux linux_kernel 6.9
linux linux_kernel From 5.15.154 (inc) to 5.16 (exc)
linux linux_kernel 6.9
linux linux_kernel From 6.8.5 (inc) to 6.9 (exc)
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.13 (inc) to 6.18.6 (exc)
linux linux_kernel From 6.1.85 (inc) to 6.1.161 (exc)
linux linux_kernel From 6.6.26 (inc) to 6.6.121 (exc)
linux linux_kernel From 6.9.1 (inc) to 6.12.66 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-401 The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a memory leak in the Linux kernel's skb_segment_list function, which handles packets aggregated by the Generic Receive Offload (GRO) engine. Due to a change in how socket memory ownership is managed for packet fragments, the function incorrectly subtracts memory accounting for fragments that are no longer charged to the socket. This causes an under-count of memory when the parent socket buffer (SKB) is freed, leading to a persistent memory leak that prevents proper socket destruction.


How can this vulnerability impact me? :

The memory leak caused by this vulnerability can lead to increased memory usage in the kernel, as socket memory allocations are not properly freed. Over time, this can degrade system performance, cause resource exhaustion, and potentially lead to denial of service conditions due to inability to allocate new sockets or network buffers.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing memory leaks related to socket memory accounting in the Linux kernel. Specifically, the leak can be observed via KMEMLEAK when tearing down the networking environment. You can use the kmemleak tool to detect unreferenced objects indicating memory leaks. For example, enabling kmemleak and checking its output with commands like: 1. echo scan > /sys/kernel/debug/kmemleak 2. cat /sys/kernel/debug/kmemleak This will show unreferenced objects such as socket allocations that were not freed properly, which is indicative of this vulnerability.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version that includes the fix for this vulnerability. The fix removes the incorrect truesize adjustment in skb_segment_list() for SKB_GSO_FRAGLIST packets and preserves the call to skb_release_head_state() to correctly manage socket memory accounting. Until the kernel is updated, monitoring for memory leaks using kmemleak and limiting exposure to heavy GRO packet forwarding may help reduce impact.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart