CVE-2026-22979: net: fix memory leak in skb_segment_list for GRO packets
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().
Security readout for executives and security teams
Plain-English summary
CVE-2026-22979 is a Linux kernel networking memory leak. Under specific packet forwarding conditions, the kernel can keep socket memory accounted after the socket should be destroyed. The business risk is gradual resource loss on affected systems, especially network-heavy hosts, but the provided sources do not establish active exploitation or severity scoring.
Executive priority
Treat this as a targeted kernel maintenance issue, not an emergency based on the supplied evidence. Prioritize patch validation for network-forwarding infrastructure because persistent leaks can degrade availability over time. Escalate urgency if vendor advisories later assign high severity or report exploitation.
Technical view
The flaw is in skb_segment_list() handling GRO-created SKB_GSO_FRAGLIST packets. After a prior ownership-transfer change orphaned fraglist entries, segmentation still subtracted fragment truesize from the parent SKB. That under-count leaves sk_wmem_alloc non-zero when the head is freed, preventing socket destruction and causing persistent memory leakage.
Likely exposure
Exposure appears limited to Linux systems running affected kernel code paths where packet forwarding processes GRO aggregated fraglist traffic. Routers, gateways, container hosts, and high-throughput network appliances may deserve closer review. The bundle lists Linux kernel versions and stable commits, but distro-specific backport status must be verified separately.
Exploitation context
The source bundle marks KEV as false and provides no evidence of active exploitation. It describes a leak observable with KMEMLEAK during networking teardown. The trigger depends on kernel packet forwarding behavior involving GRO and SKB_GSO_FRAGLIST packets; no exploit maturity or remote abuse details are provided.
Researcher notes
The available record explains root cause and fix direction but does not include CVSS, CWE, exploit status, or distro mapping. Analysis should focus on commit containment, backport verification, and workload reachability for skb_segment_list() with GRO-generated SKB_GSO_FRAGLIST traffic.
Mitigation direction
Check Linux vendor or distribution guidance for CVE-2026-22979.
Apply a kernel update containing the referenced stable fixes.
Prioritize forwarding hosts, gateways, and high-throughput network systems.
Reboot or otherwise ensure the fixed kernel is actually running.
Monitor memory pressure if patching must be delayed.
Validation and detection
Inventory running Linux kernel versions across exposed network systems.
Confirm whether installed kernels include the referenced stable fix commits.
Review distribution advisories for backported CVE-2026-22979 fixes.
Identify systems performing packet forwarding with GRO enabled workloads.
Watch for persistent socket memory growth or KMEMLEAK findings.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-22979 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 23, 2026, 15:24 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.