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.
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.
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
|||||||||||||||||||||||||||||||||
| Linux | Linux | affected |
|
Configuration 1 [-]
|
No data.
| Vendor | Product | Confidence | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Kernel | 80% |
|
Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .
Remediation
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
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 |
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
|
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