CVE-2026-43503
Fecha de publicación:
23/05/2026
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
net: skbuff: propagate shared-frag marker through frag-transfer helpers<br />
<br />
Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail<br />
to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when<br />
moving frags from source to destination. __pskb_copy_fclone() defers<br />
the rest of the shinfo metadata to skb_copy_header() after copying<br />
frag descriptors, but that helper only carries over gso_{size,segs,<br />
type} and never touches skb_shinfo()->flags; skb_shift() moves frag<br />
descriptors directly and leaves flags untouched. As a result, the<br />
destination skb keeps a reference to the same externally-owned or<br />
page-cache-backed pages while reporting skb_has_shared_frag() as<br />
false.<br />
<br />
The mismatch is harmful in any in-place writer that uses<br />
skb_has_shared_frag() to decide whether shared pages must be detoured<br />
through skb_cow_data(). ESP input is one such writer (esp4.c,<br />
esp6.c), and a single nft &#39;dup to &#39; rule -- or any other<br />
nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()&#39;d<br />
skb in esp_input() with the marker stripped, letting an unprivileged<br />
user write into the page cache of a root-owned read-only file via<br />
authencesn-ESN stray writes.<br />
<br />
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors<br />
were actually moved from the source. skb_copy() and skb_copy_expand()<br />
share skb_copy_header() too but linearize all paged data into freshly<br />
allocated head storage and emerge with nr_frags == 0, so<br />
skb_has_shared_frag() returns false on its own; they need no change.<br />
<br />
The same omission exists in skb_gro_receive() and skb_gro_receive_list().<br />
The former moves the incoming skb&#39;s frag descriptors into the<br />
accumulator&#39;s last sub-skb via two paths (a direct frag-move loop and<br />
the head_frag + memcpy path); the latter chains the incoming skb whole<br />
onto p&#39;s frag_list. Downstream skb_segment() reads only<br />
skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb&#39;s<br />
shinfo as the nskb -- both p and lp must carry the marker.<br />
<br />
The same omission also exists in tcp_clone_payload(), which builds an<br />
MTU probe skb by moving frag descriptors from skbs on sk_write_queue<br />
into a freshly allocated nskb. The helper falls into the same family<br />
and warrants the same fix for consistency; no TCP TX-side in-place<br />
writer is currently known to reach a user page through this gap, but<br />
a future consumer depending on the marker would regress silently.<br />
<br />
The same omission exists in skb_segment(): the per-iteration flag<br />
merge takes only head_skb&#39;s flag, and the inner switch that rebinds<br />
frag_skb to list_skb on head_skb-frags exhaustion does not fold the<br />
new frag_skb&#39;s flag into nskb. Fold frag_skb&#39;s flag at both sites<br />
so segments drawing frags from frag_list members carry the marker.
Gravedad: Pendiente de análisis
Última modificación:
25/05/2026