CVE-2026-43503

*** 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()-&gt;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()-&gt;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 &amp;#39;dup to &amp;#39; rule -- or any other<br /> nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()&amp;#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&amp;#39;s frag descriptors into the<br /> accumulator&amp;#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&amp;#39;s frag_list. Downstream skb_segment() reads only<br /> skb_shinfo(p)-&gt;flags, and skb_segment_list() reuses each sub-skb&amp;#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&amp;#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&amp;#39;s flag into nskb. Fold frag_skb&amp;#39;s flag at both sites<br /> so segments drawing frags from frag_list members carry the marker.