xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() (CVE-2026-64566) | HOL Guard CVE

Critical · CVSS 9.8CVE-2026-64566

xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()

Answer in brief

CVE-2026-64566 records a Critical severity (CVSS 9.8) vulnerability in xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Aug 5, 2026Updated Aug 17, 2026Source checked Sep 20, 2026First seen by HOL Aug 5, 2026Material review Aug 17, 2026

Upstream Advisory

Key facts

Risk: Critical · CVSS 9.8
Exploitation: Not marked as known exploited
Affected software: 2 mapped packages or products
Fix availability: Available

Why this deserves its current priority

CVSS is 9.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Linux/Linuxgeneric	>=5f2b6a9095743a6bf1f34c43c4fe78fa8bdf5ad7 <d8aaf06b29f5a0b6186cf68d21c7d63678ee3891 \|\| >=5f2b6a9095743a6bf1f34c43c4fe78fa8bdf5ad7 <ffd64e0717efd83fbf3396ab4e5ac6d795dac4d0 \|\| >=5f2b6a9095743a6bf1f34c43c4fe78fa8bdf5ad7 <430ea57d6daf765e88f90046afbfd1e071cb7200	d8aaf06b29f5a0b6186cf68d21c7d63678ee3891, ffd64e0717efd83fbf3396ab4e5ac6d795dac4d0, 430ea57d6daf765e88f90046afbfd1e071cb7200
Linux/Linuxgeneric	6.14	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Linux/Linux, Linux/Linux.
Review the reported fix. Update Linux/Linux to d8aaf06b29f5a0b6186cf68d21c7d63678ee3891 if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

Published upstream
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Aug 5, 2026

Sources and claim methodology

Upstream source description

In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.

Quoted source text, attributed separately from HOL analysis.