{"id":"CVE-2026-22979","title":"net: fix memory leak in skb_segment_list for GRO packets","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix memory leak in skb_segment_list for GRO packets\n\nWhen skb_segment_list() is called during packet forwarding, it handles\npackets that were aggregated by the GRO…","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= 2eeab8c47c3c0276e0746bc382f405c9a236a5ad < 0b27828ebd1ed3107d7929c3737adbe862e99e74","Linux >= fc126c1d51e9552eacd2d717b9ffe9262a8a4cd6 < 88bea149db2057112af3aaf63534b24fab5858ab","Linux >= ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 < 3264881431e308b9c72cb8a0159d57a56d67dd79","Linux >= ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 < c114a32a2e70b82d447f409f7ffcfa3058f9d5bd","Linux >= ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 < 238e03d0466239410b72294b79494e43d4fabe77","Linux d225b0ac96dc40d7e8ae2bc227eb2c56e130975f","Linux 5b3b67f731296027cceb3efad881ae281213f86f","Linux >= 6.1.85 < 6.1.161","Linux >= 6.6.26 < 6.6.121","Linux >= 5.15.154 < 5.16","Linux >= 6.8.5 < 6.9","Linux 6.9"],"published":"2026-01-23","updated":"2026-09-08","sourceUpdated":"2026-09-08T08:44:26.536Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-22979","references":[{"url":"https://git.kernel.org/stable/c/0b27828ebd1ed3107d7929c3737adbe862e99e74"},{"url":"https://git.kernel.org/stable/c/88bea149db2057112af3aaf63534b24fab5858ab"},{"url":"https://git.kernel.org/stable/c/3264881431e308b9c72cb8a0159d57a56d67dd79"},{"url":"https://git.kernel.org/stable/c/c114a32a2e70b82d447f409f7ffcfa3058f9d5bd"},{"url":"https://git.kernel.org/stable/c/238e03d0466239410b72294b79494e43d4fabe77"}],"tags":["cve.org"],"epss":0.00139,"epssPercentile":0.03609,"ingestedAt":"2026-09-08T15:33:26.994Z","slug":"CVE-2026-22979","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix memory leak in skb_segment_list for GRO packets\n\nWhen skb_segment_list() is called during packet forwarding, it handles\npackets that were aggregated by the GRO engine.\n\nHistorically, the segmentation logic in skb_segment_list assumes that\nindividual segments are split from a parent SKB and may need to carry\ntheir own socket memory accounting. Accordingly, the code transfers\ntruesize from the parent to the newly created segments.\n\nPrior to commit ed4cccef64c1 (\"gro: fix ownership transfer\"), this\ntruesize subtraction in skb_segment_list() was valid because fragments\nstill carry a reference to the original socket.\n\nHowever, commit ed4cccef64c1 (\"gro: fix ownership transfer\") changed\nthis behavior by ensuring that fraglist entries are explicitly\norphaned (skb->sk = NULL) to prevent illegal orphaning later in the\nstack. This change meant that the entire socket memory charge remained\nwith the head SKB, but the corresponding accounting logic in\nskb_segment_list() was never updated.\n\nAs a result, the current code unconditionally adds each fragment's\ntruesize to delta_truesize and subtracts it from the parent SKB. Since\nthe fragments are no longer charged to the socket, this subtraction\nresults in an effective under-count of memory when the head is freed.\nThis causes sk_wmem_alloc to remain non-zero, preventing socket\ndestruction and leading to a persistent memory leak.\n\nThe leak can be observed via KMEMLEAK when tearing down the networking\nenvironment:\n\nunreferenced object 0xffff8881e6eb9100 (size 2048):\n  comm \"ping\", pid 6720, jiffies 4295492526\n  backtrace:\n    kmem_cache_alloc_noprof+0x5c6/0x800\n    sk_prot_alloc+0x5b/0x220\n    sk_alloc+0x35/0xa00\n    inet6_create.part.0+0x303/0x10d0\n    __sock_create+0x248/0x640\n    __sys_socket+0x11b/0x1d0\n\nSince skb_segment_list() is exclusively used for SKB_GSO_FRAGLIST\npackets constructed by GRO, the truesize adjustment is removed.\n\nThe call to skb_release_head_state() must be preserved. As documented in\ncommit cf673ed0e057 (\"net: fix fraglist segmentation reference count\nleak\"), it is still required to correctly drop references to SKB\nextensions that may be overwritten during __copy_skb_header().\n\n## Affected\n\n- `Linux >= 2eeab8c47c3c0276e0746bc382f405c9a236a5ad < 0b27828ebd1ed3107d7929c3737adbe862e99e74`\n- `Linux >= fc126c1d51e9552eacd2d717b9ffe9262a8a4cd6 < 88bea149db2057112af3aaf63534b24fab5858ab`\n- `Linux >= ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 < 3264881431e308b9c72cb8a0159d57a56d67dd79`\n- `Linux >= ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 < c114a32a2e70b82d447f409f7ffcfa3058f9d5bd`\n- `Linux >= ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 < 238e03d0466239410b72294b79494e43d4fabe77`\n- `Linux d225b0ac96dc40d7e8ae2bc227eb2c56e130975f`\n- `Linux 5b3b67f731296027cceb3efad881ae281213f86f`\n- `Linux >= 6.1.85 < 6.1.161`\n- `Linux >= 6.6.26 < 6.6.121`\n- `Linux >= 5.15.154 < 5.16`\n- `Linux >= 6.8.5 < 6.9`\n- `Linux 6.9`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}