PT-2026-106697 · Linux · Linux
CVE-2026-98368
·
Published
2026-10-06
·
Updated
2026-10-06
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
esp: downgrade zerocopy managed frags before mutating skb frags
On the out-of-place output path (esp->inplace == false) ESP rewrites the
skb frag array: esp output head() appends a trailer frag and
esp output tail() replaces the frags with a destination page, both
referenced with get page().
When the skb carries zerocopy managed frags (SKBFL MANAGED FRAG REFS) the
payload frags are owned by the ubuf and must not be referenced or
unreferenced individually, but ESP mutates the frag array without ever
downgrading the skb. This breaks the managed-frag invariant two ways:
-
esp ssg unref() walks the source scatterlist and drops a page reference for every frag, including the ubuf-owned payload frags, pushing their refcount below the GUP pin bias while the pages are still pinned, i.e. a use-after-free of the zerocopy pages;
-
esp output tail() installs its destination page as frag 0 with get page() but leaves SKBFL MANAGED FRAG REFS set, so skb release data() takes the skip unref branch and never drops that reference, leaking the x->xfrag page at packet rate.
Fix this the way every other frag-mutating site does ( ip append data(),
ip6 append data(), tcp sendmsg locked()) and call
skb zcopy downgrade managed() before ESP touches the frag array: it takes
a real reference on each existing frag and clears SKBFL MANAGED FRAG REFS,
so the per-frag unref in esp ssg unref() and the frag release in
skb release data() are both balanced and no mixed-ownership frag array is
left behind.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux