Cloudanix VulnDB

CVE-2026-99055

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's handling of special network memory buffers during fast data copying can crash the entire system when certain network traffic arrives.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Null pointer dereference in can_map_frag during tcp_zerocopy_receive when skb_frag_page returns NULL for a net_iov fragment passed from find_next_mappable_frag after a readable prefix.

Why it matters to the business

Kernel panic and system crash on affected Linux hosts using zerocopy TCP receive with certain memory-mapped receive buffers, leading to denial of service and potential loss of network sessions.

How an attack unfolds

An attacker establishes a TCP connection and sends data structured as a short readable prefix followed by an unreadable NET_IOV_DMABUF or IOURING fragment; tcp_zerocopy_receive then invokes the faulty mapping path that dereferences the null page pointer.

How to fix it

Apply the upstream kernel patch that adds an early guard rejecting net_iov fragments in tcp_zerocopy_set_hint_for_skb before any skb_frag_page or PageCompound call; rebuild and deploy the fixed kernel image.

How to confirm the fix worked

Reproduce the original test case with a 64-byte readable prefix plus 4096-byte NET_IOV_DMABUF fragment and confirm the kernel no longer panics; verify the guard condition is present in the compiled tcp.c or equivalent source.

Typical attack path

  1. Establish TCP socket with zerocopy receive enabled
  2. Send crafted payload containing 64-byte readable prefix followed by unreadable net_iov fragment
  3. Trigger receive_fallback_to_copy and subsequent hint calculation
  4. Cause skb_frag_page to return NULL and can_map_frag to dereference it
  5. Induce KASAN null-ptr-deref and kernel panic

How to detect it

Search kernel logs for KASAN null-ptr-deref reports mentioning can_map_frag or tcp_zerocopy_receive; correlate with TCP connections using zerocopy receive and net_iov or DMABUF fragments.

What your security team should do

  • Prioritize kernel upgrade on all systems exposing TCP zerocopy receive paths
  • Monitor for upcoming stable kernel releases containing the fix
  • Temporarily disable TCP zerocopy receive where feasible until patched
  • Audit custom or embedded Linux builds for backported net_iov handling changes

The record

In the Linux kernel, the following vulnerability has been resolved: tcp: reject net_iov in zerocopy receive mapping hints After copying a readable prefix, receive_fallback_to_copy() asks tcp_zerocopy_set_hint_for_skb() where page mapping can resume. If the next skb is unreadable, find_next_mappable_frag() passes its net_iov fragment to can_map_frag(). skb_frag_page() returns NULL for a net_iov, but can_map_frag() dereferences it in PageCompound(). A v7.2 KASAN run on a connected TCP socket with 64 readable bytes followed by a 4096-byte NET_IOV_DMABUF fragment reported: BUG: KASAN: null-ptr-deref in can_map_frag tcp_zerocopy_receive -> can_map_frag Kernel panic - not syncing: KASAN: panic_on_warn set The diagnostic inserted the net_iov directly because the test host has no devmem-capable NIC. Hardware end-to-end reachability remains untested and requires CONFIG_NET_DEVMEM plus a supported DMA-buf-bound RX queue. Reject all net_iov fragments before skb_frag_page(). This covers both DMABUF and IOURING net_iov types while leaving page-backed checks unchanged. With the guard, the same queue copied the readable prefix, returned a 4096-byte skip hint, and completed without a fault.

Affected packages

Ecosystem Package Introduced Fixed