Cyber Resilience

CVE-2026-43503

HighUpdated

Published: 23 May 2026

Published
23 May 2026
Modified
30 June 2026
KEV Added
Patch
CVSS Score v3.1 8.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
EPSS Score 0.0013 3.0th percentile
Risk Priority 55 floored blend · peak EPSS

Summary

CVE-2026-43503 is a high-severity Improper Control of a Resource Through its Lifetime (CWE-664) vulnerability in Linux Linux Kernel. Its CVSS base score is 8.8 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 3.0th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

EU & UK References

Vulnerability details

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()…

more

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.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise TechniquesAI

T1068 Exploitation for Privilege Escalation Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges.
Why these techniques?

Kernel skb frag marker mishandling directly enables local unprivileged arbitrary writes into protected page cache, facilitating privilege escalation via in-place writers like ESP.

Confidence: HIGH · MITRE ATT&CK Enterprise v19.0

Affected Assets

linux
linux kernel
7.1 · 3.9 — 5.10.257 · 5.11 — 5.15.208 · 5.16 — 6.1.174

Mitigating Controls

Likely Mitigating Controls AI

Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.

addresses: CWE-664

Requires a managed development lifecycle process with integrity controls on changes, improving control of resources throughout their lifetime.

addresses: CWE-664

Requires designing resource lifetime controls that anticipate, withstand, and recover from stresses or attacks, mitigating improper resource control.

addresses: CWE-664

Directly enforces limited resource lifetime by requiring initiation from a known state and explicit termination, shrinking the window any long-lived resource weakness can be exploited.

References