Linux Kernel TCP stack Improper Control Of A Resource Through Its Lifetime Rated 8.8 CVSS

Status: UPDATED  |  Advisory ID: CVE-2026-43503

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux, Red Hat, and Siemens's web pages for any future patch releases.

References