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.
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.
Metrics
Affected Vendors & Products
Configuration 1 [-]
|
No data.
OpenCVE Enrichment is a feature of OpenCVE that uses AI to automatically link vendors and products to CVEs. Learn more on GitHub.
| Vendors | Products |
|---|---|
|
Linux
Subscribe
|
Kernel
Subscribe
|
Advisories
| Source | ID | Title |
|---|---|---|
 Debian DLA |
DLA-4606-1 | linux security update |
| Debian DLA |
DLA-4607-1 | linux-6.1 security update |
 Debian DSA |
DSA-6295-1 | linux security update |
| Debian DSA |
DSA-6306-1 | linux security update |
 Ubuntu USN |
USN-8370-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8371-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8373-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8374-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8426-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-8426-2 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-8440-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-8489-1 | Linux kernel (OEM) vulnerabilities |
| Ubuntu USN |
USN-8497-1 | Linux kernel (Low Latency) vulnerabilities |
| Ubuntu USN |
USN-8499-1 | Linux kernel (Xilinx) vulnerabilities |
| Ubuntu USN |
USN-8528-1 | Linux kernel (Xilinx ZynqMP) vulnerabilities |
| Ubuntu USN |
USN-8569-1 | Linux kernel (HWE) vulnerabilities |
| Ubuntu USN |
USN-8388-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8388-2 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8393-1 | Linux kernel (Azure FIPS) vulnerabilities |
| Ubuntu USN |
USN-8461-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-8462-1 | Linux kernel (Oracle) vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Tue, 26 May 2026 16:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-787 | |
| CPEs | 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:*:*:*:*:*:* |
Tue, 26 May 2026 13:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Mon, 25 May 2026 06:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Sat, 23 May 2026 13:30:00 +0000
| Type | Values Removed | Values 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. | 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. |
| Title | net: skbuff: propagate shared-frag marker through frag-transfer helpers | net: skbuff: preserve shared-frag marker during coalescing |
| References |
|
|
Sat, 23 May 2026 12:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | A flaw was found in the Linux kernel's XFRM ESP-in-TCP subsystem. This vulnerability, known as Fragnesia, allows a local attacker to achieve arbitrary byte writes into the kernel page cache of read-only files. | 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. |
| Title | kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel | net: skbuff: propagate shared-frag marker through frag-transfer helpers |
| First Time appeared |
Linux linux Kernel
|
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux linux Kernel
|
|
| References |
|
|
Thu, 14 May 2026 14:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Linux
Linux kernel |
|
| Vendors & Products |
Linux
Linux kernel |
Thu, 14 May 2026 12:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | A flaw was found in the Linux kernel's XFRM ESP-in-TCP subsystem. This vulnerability, known as Fragnesia, allows a local attacker to achieve arbitrary byte writes into the kernel page cache of read-only files. | |
| Title | kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel | |
| Weaknesses | CWE-123 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-08-05T12:31:05.381Z
Reserved: 2026-05-13T15:03:33.111Z
Link: CVE-2026-46300
Vulnrichment
No data.
NVD
Status : Modified
Published: 2026-05-23T12:17:02.660
Modified: 2026-07-23T11:10:00.120
Link: CVE-2026-46300
Redhat
OpenCVE Enrichment
Updated: 2026-08-05T03:15:05Z