Linux: Insufficient Control Flow Management

What to do

1. Update Linux to fbeab9555564a1b98e8582cd106dfe46c4606991 or 179f1852bdedc300e373e807cc102cd81feff196 or 12401fcfb01f53ccc63ab0a3246570fe8f3105ee or 989214c66884d70716d83dc1d0bf5e16287bf349, whichever matches your release line, or a later version.
2. Update Linux Kernel to 5.10.257 or 5.15.208 or 6.1.174 or 6.6.141, whichever matches your release line, or a later version.

Affected products and versions

Version data comes from the organisation that assigned the CVE; 6 further products are omitted here. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector

LocalThe attacker needs local access or must trick a user into running something.

Attack complexity

LowNo special conditions are needed; the attack works reliably.

Privileges required

LowA basic user account is enough.

User interaction

NoneNo action by a victim is required.

Scope

ChangedThe attack can reach beyond the vulnerable component into other systems.

Confidentiality

HighAll data handled by the component can be read.

Integrity

HighData or code can be modified at will.

Availability

HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Scored by CNA.

Official description

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.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Insufficient Control Flow Management

Timeline

1. May 23, 2026CVE record published.
2. October 16, 2026CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
3. October 16, 2026Record last changed materially (score, affected products, status or references).

References

Recent Insufficient Control Flow Management vulnerabilities

• 7.4 High severity

  Intel(R) PROSet/Wireless WiFi Software for…: Insufficient Control Flow Management

  CVE-2025-35963Nov 11, 2025Intel(R) PROSet/Wireless WiFi Software for Windows
• 7.8 High severity

  Intel(R) 700 Series Ethernet: Insufficient Control Flow Management

  CVE-2025-25273Aug 12, 2025Intel(R) 700 Series Ethernet
• 7.2 High severity

  Intel(R) Xeon(R) processors: Insufficient Control Flow Management

  CVE-2025-24305Aug 12, 2025Intel(R) Xeon(R) Processors
• 7.8 High severity

  Intel(R) 800 Series Ethernet: Insufficient Control Flow Management

  CVE-2025-22893Aug 12, 2025Intel(R) 800 Series Ethernet
• 7.2 High severity

  Intel(R) Xeon(R) 6 processor E-Cores firmware: Insufficient Control Flow Management

  CVE-2025-20004May 13, 2025Intel(R) Xeon(R) 6 processor E-Cores firmware
• 7.8 High severity

  Intel(R) VROC software: Insufficient Control Flow Management

  CVE-2024-29079Nov 13, 2024Intel(R) VROC software

Spotted an error? Tell us.