CVE-2026-98368

esp: downgrade zerocopy managed frags before mutating skb frags

State
Published
Severity
7.8 High
Published
Oct 6, 2026
Updated
Oct 19, 2026
Reserved
Sep 25, 2026

Read the record on cve.org

Description

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.

Scores

CVSSScoreVectorSource
3.17.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HLinux

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • 753f1ca4e1e50248a1b760c9774d6d6b354562cc to before 2359264f377cdbdef2d95868cc8fb572949e48d3Affected
  • 753f1ca4e1e50248a1b760c9774d6d6b354562cc to before 69a768c12398cada8528080332c822623fa7064dAffected
  • 753f1ca4e1e50248a1b760c9774d6d6b354562cc to before 6508304ac2c8cdafca2f4ab915df8c707893e134Affected
  • 753f1ca4e1e50248a1b760c9774d6d6b354562cc to before 6cab554f2c0f28773f712ed3a5479103f42ce844Affected
  • 753f1ca4e1e50248a1b760c9774d6d6b354562cc to before 0d0845ee61c5df47cc68bc446501f48f71e8dcc6Affected
  • 753f1ca4e1e50248a1b760c9774d6d6b354562cc to before f89416eb3db151170a6f3c6dfc5239d26cdce4d2Affected
LinuxLinux
  • 6.0Affected
  • before 6.0Not affected
  • 6.1.189 through 6.1.*Not affected
  • 6.6.158 through 6.6.*Not affected
  • 6.12.112 through 6.12.*Not affected
  • 6.18.54 through 6.18.*Not affected
  • 7.2.8 through 7.2.*Not affected
  • 7.3 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.