CVE-2026-98368: esp: downgrade zerocopy managed frags before mutating skb frags
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: espoutputhead() appends a trailer frag and espoutputtail() replaces the frags with a destination page, both referenced with getpage().
When the skb carries zerocopy managed frags (SKBFLMANAGEDFRAGREFS) 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:
- espssgunref() 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;
- espoutputtail() installs its destination page as frag 0 with getpage() but leaves SKBFLMANAGEDFRAGREFS set, so skbreleasedata() takes the skipunref branch and never drops that reference, leaking the x->xfrag page at packet rate.
Fix this the way every other frag-mutating site does (ipappenddata(), ip6appenddata(), tcpsendmsglocked()) and call skbzcopydowngrademanaged() before ESP touches the frag array: it takes a real reference on each existing frag and clears SKBFLMANAGEDFRAGREFS, so the per-frag unref in espssgunref() and the frag release in skbreleasedata() are both balanced and no mixed-ownership frag array is left behind.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Call skb_zcopy_downgrade_managed() before ESP mutates the skb frag array, including in esp_output_tail() and esp_output_head(), to obtain real references for existing frags and clear SKBFL_MANAGED_FRAG_REFS.
Event History
Frequently Asked Questions
Which traffic path is exposed to this issue?
The issue is in the ESP out-of-place output path, where esp->inplace is false, and applies when the skb contains zerocopy managed fragments marked SKBFL_MANAGED_FRAG_REFS.
What are the operational consequences if the affected path is used?
The source scatterlist cleanup can drop references to ubuf-owned pinned payload pages, causing a use-after-free while those pages remain pinned. The path can also leak the ESP destination x->xfrag page for each packet processed.
Is the in-place ESP output path identified as affected?
The provided information specifically identifies the out-of-place path. It does not identify the path where esp->inplace is true as affected.