CVE-2026-99055 in Linux
Summary
by MITRE • 10/23/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel TCP stack contains a critical null pointer dereference vulnerability within its zero-copy receive mechanism, specifically affecting how network I/O vectors are handled during memory mapping operations. This flaw resides in the interaction between the tcp_zerocopy_set_hint_for_skb function and the can_map_frag helper routine. When processing incoming data on a connected TCP socket, the kernel attempts to optimize performance by allowing user-space applications to map received packets directly into their address space without copying. However, under specific conditions involving non-standard memory types such as DMA buffers or IOURING network I/O vectors, this optimization logic fails to properly validate the underlying page structures before attempting access.
The technical root cause lies in the find_next_mappable_frag function which identifies fragments suitable for mapping and passes them to can_map_frag for validation. When a packet contains a readable prefix followed by a fragment backed by net_iov rather than traditional physical pages, the skb_frag_page macro returns NULL because network I/O vectors do not have associated page structures in the conventional sense. Despite this null return value, can_map_frag proceeds to dereference the result within its PageCompound check logic. This unconditional dereference triggers a kernel panic when running under KASAN with panic_on_warn enabled, effectively causing a denial of service for any process utilizing zero-copy TCP receive operations on affected systems.
The operational impact is significant as it allows an attacker or misbehaving network traffic to crash the local system simply by sending specific packet sequences that trigger this code path. While the vulnerability requires CONFIG_NET_DEVMEM and supported DMA-buf-bound RX queues in production environments, the logic flaw exists regardless of hardware capabilities because the kernel must handle all incoming fragments correctly even if they cannot be mapped for zero-copy purposes. The absence of proper validation means that any TCP connection attempting to use zerocopy hints with mixed fragment types risks triggering this null pointer dereference, leading to immediate system instability and potential data loss due to abrupt termination of network services.
This vulnerability aligns with CWE-476 which describes a NULL Pointer Dereference error where the software performs an operation on a pointer that is expected to be valid but is actually null. In terms of attack vectors, this falls under ATT&CK technique T1053 Scheduled Task/Job as it represents a local privilege escalation or denial of service vector that could potentially be triggered remotely via crafted network packets if zero-copy features are enabled and exposed through application interfaces like sendmsg with MSG_ZEROCOPY. The lack of input validation on fragment types before structural access is the primary security failure here.
The resolution involves modifying tcp_zerocopy_set_hint_for_skb to reject all net_iov fragments prior to calling skb_frag_page. This guard ensures that both DMABUF and IOURING network I/O vector types are filtered out early in the processing pipeline, preventing them from reaching the can_map_frag function where they would cause a crash. By rejecting these incompatible fragment types before page structure validation, the kernel maintains stability while preserving correct behavior for standard page-backed buffers. This fix leaves existing checks for physical pages unchanged and ensures that readable prefixes are correctly copied while skip hints are returned appropriately without triggering faults.
To mitigate this risk in environments where patching is not immediately possible, administrators should consider disabling zero-copy TCP receive optimizations if they are not strictly required by their applications. Disabling MSG_ZEROCOPY usage in network-heavy services reduces the attack surface for this specific code path. Additionally ensuring that kernel updates are applied promptly upon release of patches addressing CVE details related to tcp_zerocopy_receive is essential for maintaining system integrity against potential denial-of-service attacks exploiting this null pointer dereference flaw.