Answer in brief
CVE-2026-64566 records a Unknown severity 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.
A CVSS score is not reported in the current record. 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.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=5f2b6a9095743a6bf1f34c43c4fe78fa8bdf5ad7 <d8aaf06b29f5a0b6186cf68d21c7d63678ee3891 || >=5f2b6a9095743a6bf1f34c43c4fe78fa8bdf5ad7 <ffd64e0717efd83fbf3396ab4e5ac6d795dac4d0 || >=5f2b6a9095743a6bf1f34c43c4fe78fa8bdf5ad7 <430ea57d6daf765e88f90046afbfd1e071cb7200 | d8aaf06b29f5a0b6186cf68d21c7d63678ee3891, ffd64e0717efd83fbf3396ab4e5ac6d795dac4d0, 430ea57d6daf765e88f90046afbfd1e071cb7200 |
| Linux/Linuxgeneric | 6.14 | Not reported |
Published upstream
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Answer in brief
CVE-2026-64566 records a Unknown severity 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.
A CVSS score is not reported in the current record. 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.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=5f2b6a9095743a6bf1f34c43c4fe78fa8bdf5ad7 <d8aaf06b29f5a0b6186cf68d21c7d63678ee3891 || >=5f2b6a9095743a6bf1f34c43c4fe78fa8bdf5ad7 <ffd64e0717efd83fbf3396ab4e5ac6d795dac4d0 || >=5f2b6a9095743a6bf1f34c43c4fe78fa8bdf5ad7 <430ea57d6daf765e88f90046afbfd1e071cb7200 | d8aaf06b29f5a0b6186cf68d21c7d63678ee3891, ffd64e0717efd83fbf3396ab4e5ac6d795dac4d0, 430ea57d6daf765e88f90046afbfd1e071cb7200 |
| Linux/Linuxgeneric | 6.14 | Not reported |
Published upstream
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.