Cloudanix VulnDB

CVE-2026-98368

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux kernel network encryption code can let someone already on the system crash it or potentially gain higher access by mishandling memory references.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

ESP output path mutates skb frag array on out-of-place processing without first calling skb_zcopy_downgrade_managed, violating managed-frag ownership rules and causing either use-after-free of zerocopy pages (via esp_ssg_unref) or reference leaks (via esp_output_tail leaving SKBFL_MANAGED_FRAG_REFS set).

Why it matters to the business

Local attackers on Linux systems can trigger kernel memory corruption, leading to crashes, denial of service, or potential privilege escalation; high-prevalence kernel component means broad exposure across servers, containers, and network appliances until patched.

How an attack unfolds

An attacker with local access sends or triggers ESP traffic that takes the out-of-place path (esp->inplace==false), ensuring the skb carries SKBFL_MANAGED_FRAG_REFS; the missing downgrade allows esp_ssg_unref to underflow GUP pins or skb_release_data to skip a required put_page, resulting in UAF or leaked pages.

How to fix it

Update to a Linux kernel containing the referenced fix that invokes skb_zcopy_downgrade_managed() before any ESP frag-array mutation; rebuild and reboot affected systems; where immediate patching is impossible, restrict local access and avoid zerocopy paths if configurable.

How to confirm the fix worked

Verify the presence of the skb_zcopy_downgrade_managed call in esp_output_head/esp_output_tail paths via source inspection or kernel binary diff; confirm no SKBFL_MANAGED_FRAG_REFS remains set after ESP processing on test skbs; re-test with zerocopy-enabled workloads.

Typical attack path

  1. Obtain local unprivileged access on a Linux host
  2. Trigger IPsec ESP output processing that selects the non-inplace code path with a zerocopy skb
  3. Cause esp_output_head or esp_output_tail to mutate the frag array without downgrade
  4. Induce esp_ssg_unref or skb_release_data to perform unbalanced page operations
  5. Trigger use-after-free or memory leak leading to crash or further exploitation

How to detect it

Search kernel logs and crash dumps for page reference underflow or leak messages originating from esp_ssg_unref or skb_release_data in the ESP path; correlate with network activity involving IPsec ESP and zerocopy sockets.

What your security team should do

  • Prioritize kernel updates on all internet-facing and multi-tenant systems within the next patch cycle
  • Audit workloads that enable IPsec ESP with zerocopy networking for exposure
  • Enable kernel hardening features such as page allocator hardening and KASAN in test environments to surface similar issues earlier
  • Monitor upstream stable kernel releases for backports of this change

The record

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.

Affected packages

Ecosystem Package Introduced Fixed