CVE-2026-43503
Linux Kernel 3.9 – 5.10.257
Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
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, ranked in the top 20% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-39 (Process Isolation) and SC-4 (Information in Shared System Resources) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-31536
Vulnerability Data
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
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
SC-39 enforces separate execution domains so one process cannot corrupt or misuse another process's resources across their lifetimes.
SC-4 prevents unintended information transfer through shared resources, limiting blast radius when a product fails to release or reuse resources correctly.
SI-16 blocks unauthorized code execution in memory, stopping exploitation that commonly follows improper allocation, use-after-free, or deallocation errors.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Information deletion control ensures proper release and sanitization at end of life.
A.8.25 mandates secure SDLC practices (secure requirements, checkpoints, secure coding, testing per 8.29, developer training) that reach many but not all lifetime-control defects in CWE-664; a bounded remainder (e.g. certain runtime resource mismanagement or non-software resources) is not covered by the development-lifecycle focus.
A.8.26 only requires that security requirements (including some that could address resource lifetime) be identified and specified during development or acquisition; it does not mandate or perform any removal of the CWE-664 flaw itself from existing or produced code.
Secure architecture principles reduce lifetime control issues but are not specific to them.
Secure coding practices help avoid lifetime control bugs but do not address the full scope.
Hardening callouts derived
DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.
- No fine-grained STIG row for CWE-664, a pillar-level weakness. Rules are authored against its narrower children: CWE-471.