xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()
28Vexday Risk Score
Sem sinal de exploração. Nenhum artefato público de exploração conhecido até agora.
ssvc Trackcvss 9.8epss 0.4%
probabilidade de exploração
0.4%top 72% das CVEs
exploração observada
nãonenhuma fonte reporta
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.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Produtos afetados
Linux · Linux