CVE-2026-46300
net: skbuff: preserve shared-frag marker during coalescing
Description
In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.
INFO
Published Date :
May 23, 2026, 12:17 p.m.
Last Modified :
May 30, 2026, 11:17 a.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | HIGH | [email protected] | ||||
| CVSS 3.1 | HIGH | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
Solution
- Set SKBFL_SHARED_FRAG on destination when frag descriptors are moved.
- Ensure skb_gro_receive() and skb_gro_receive_list() propagate the marker.
- Update tcp_clone_payload() to consistently carry the marker.
- Fold frag_skb's flag in skb_segment() at both sites.
Public PoC/Exploit Available at Github
CVE-2026-46300 has a 35 public
PoC/Exploit available at Github.
Go to the Public Exploits tab to see the list.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-46300.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-46300 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-46300
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Go-based Scanner for several 2025-2026 Linux root kernel vulnerabilities (DirtyFrag, Fragnesia, Copy Fail, Fragnesia, DirtyPipe)
Makefile Go
None
Python C Shell PHP PowerShell ASP.NET
Add go CVE-2026-46300 (Fragnesia) local privilege escalation exploit
Go
Herramienta de análisis pasivo para detectar exposición de Copy-Fail, Dirty Frag y Fragnesia en sistemas Linux.
Shell
old traitor with new exploits
Go C
None
Dockerfile C Shell
None
None
HTML Python C
None
Go
RootHawkX 是一个 Linux 本地安全测试终端工具,本项目基于RootHawk进行修改，集成了更多漏洞利用模块。
Go C Batchfile Shell
None
Reproducible isolated lab for verifying Inner Warden's detection of public Linux kernel CVEs. Clone, follow the per-CVE recipe, watch the autonomous agent react on your own VM.
Shell
Multi-architecture Linux privilege escalation toolkit with 19 pre-built and runtime-compilable exploits. Auto-detects kernel version, filters patched exploits, tries each until root.
ctf cybersecurity exploit gtfobins kernel-exploit linux penetration-testing privilege-escalation security
Makefile Shell C Go
Патч-скрипты для устранения критических уязвимостей (Copy Fail, Dirty Frag, PinTheft, GRO Frag) в РЕД ОС 7.3 и РЕД ОС 8.0
fstec linux-kernel security-scripts red-os cve-mitigation
Shell
A Go implementation of dirtydecrypt (CVE-2026-31635)
Go
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-46300 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-46300 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 30, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H -
Initial Analysis by [email protected]
May. 26, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Added CWE CWE-787 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 3.9 up to (including) 5.10.257 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.11 up to (excluding) 5.15.208 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.16 up to (excluding) 6.1.174 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.2 up to (excluding) 6.6.141 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.7 up to (excluding) 6.12.91 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.13 up to (excluding) 6.18.33 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.19 up to (excluding) 7.0.10 Added Reference Type CVE: http://www.openwall.com/lists/oss-security/2026/05/13/5 Types: Mailing List Added Reference Type CVE: http://www.openwall.com/lists/oss-security/2026/05/21/11 Types: Mailing List Added Reference Type CVE: http://www.openwall.com/lists/oss-security/2026/05/21/12 Types: Mailing List Added Reference Type CVE: http://www.openwall.com/lists/oss-security/2026/05/21/13 Types: Mailing List Added Reference Type kernel.org: https://git.kernel.org/stable/c/2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/3599e6b3cc1ada96883d496a50a210d3afbb6987 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/3884358a9286b17f389a72b1426fc4547c23c111 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/3bd9e113d50034db99d7ef69fd8e5242d15e414a Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34e Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/78bf6b6bb19541d19fbda6242e7cfe2c682763c0 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/9d3e5fd19fe1063bf607219e8562fbd567b8e8d5 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/f84eca5817390257cef78013d0112481c503b4a3 Types: Patch -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 25, 2026
Action Type Old Value New Value Added Reference https://git.kernel.org/stable/c/f84eca5817390257cef78013d0112481c503b4a3 -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 23, 2026
Action Type Old Value New Value Changed Description In the Linux kernel, the following vulnerability has been resolved: net: skbuff: propagate shared-frag marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker. In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors. Added Reference https://git.kernel.org/stable/c/2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c Added Reference https://git.kernel.org/stable/c/3599e6b3cc1ada96883d496a50a210d3afbb6987 Added Reference https://git.kernel.org/stable/c/3884358a9286b17f389a72b1426fc4547c23c111 Added Reference https://git.kernel.org/stable/c/3bd9e113d50034db99d7ef69fd8e5242d15e414a Added Reference https://git.kernel.org/stable/c/760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34e Added Reference https://git.kernel.org/stable/c/78bf6b6bb19541d19fbda6242e7cfe2c682763c0 Added Reference https://git.kernel.org/stable/c/9d3e5fd19fe1063bf607219e8562fbd567b8e8d5 Removed Reference https://git.kernel.org/stable/c/12401fcfb01f53ccc63ab0a3246570fe8f3105ee Removed Reference https://git.kernel.org/stable/c/179f1852bdedc300e373e807cc102cd81feff196 Removed Reference https://git.kernel.org/stable/c/989214c66884d70716d83dc1d0bf5e16287bf349 Removed Reference https://git.kernel.org/stable/c/9bc9d6d6967a2239aa57af2aa53554eddd640d20 Removed Reference https://git.kernel.org/stable/c/fbeab9555564a1b98e8582cd106dfe46c4606991 Removed Reference https://git.kernel.org/stable/c/fc6eb39c55e97df2f94ad974b8a5bbcd019da2c8 Removed Reference https://git.kernel.org/stable/c/ff375cc75f9167168db38e0464a482d5fbc8d81d -
CVE Modified by af854a3a-2127-422b-91ae-364da2661108
May. 23, 2026
Action Type Old Value New Value Added Reference http://www.openwall.com/lists/oss-security/2026/05/13/5 Added Reference http://www.openwall.com/lists/oss-security/2026/05/21/11 Added Reference http://www.openwall.com/lists/oss-security/2026/05/21/12 Added Reference http://www.openwall.com/lists/oss-security/2026/05/21/13 -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 23, 2026
Action Type Old Value New Value Added Description In the Linux kernel, the following vulnerability has been resolved: net: skbuff: propagate shared-frag marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker. Added Reference https://git.kernel.org/stable/c/12401fcfb01f53ccc63ab0a3246570fe8f3105ee Added Reference https://git.kernel.org/stable/c/179f1852bdedc300e373e807cc102cd81feff196 Added Reference https://git.kernel.org/stable/c/989214c66884d70716d83dc1d0bf5e16287bf349 Added Reference https://git.kernel.org/stable/c/9bc9d6d6967a2239aa57af2aa53554eddd640d20 Added Reference https://git.kernel.org/stable/c/fbeab9555564a1b98e8582cd106dfe46c4606991 Added Reference https://git.kernel.org/stable/c/fc6eb39c55e97df2f94ad974b8a5bbcd019da2c8 Added Reference https://git.kernel.org/stable/c/ff375cc75f9167168db38e0464a482d5fbc8d81d