Cloudanix VulnDB

CVE-2026-98271

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's network packet handling can cause systems to crash when processing certain incoming network messages.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

pskb_carve operations leave stale mac/network/transport/csum offsets and inner header state pointing past the new skb tail into uninitialized memory, creating a partially initialized skb that triggers invalid header accesses or kernel BUGs on subsequent operations such as skb_pull or queue purge.

Why it matters to the business

Networking workloads that perform packet header carving, especially RDS over TCP, can experience unexpected kernel crashes or panics, leading to service disruption and potential data loss on affected Linux systems.

How an attack unfolds

An attacker sends network traffic that causes pskb_carve_inside_header or pskb_carve_inside_nonlinear to be invoked (for example via RDS TCP data reception); the resulting carved skb with stale headers is queued; later release via skb_queue_purge attempts header operations on invalid offsets, triggering the BUG.

How to fix it

Apply the upstream fix that introduces skb_carve_reset_headers to invalidate all header offsets and inner state after carving; rebuild and deploy an updated kernel containing the patch.

How to confirm the fix worked

Confirm the presence of skb_carve_reset_headers in the kernel source or verify that pskb_carve callers no longer leave mac_header, network_header, or transport_header pointing beyond skb_tail_pointer.

Typical attack path

  1. Send crafted packets to a vulnerable RDS/TCP endpoint
  2. Trigger pskb_carve on the incoming skb
  3. Queue the malformed skb on ti_skb_list
  4. Release the message causing skb_queue_purge and header dereference
  5. Kernel hits BUG at skbuff.h:2847

How to detect it

Search kernel logs and drop_monitor output for skbuff BUG traces containing __skb_pull with headlen=0 and mac_header values exceeding tail; inspect RDS TCP receive paths for queue purge events on carved skbs.

What your security team should do

  • Prioritize kernel upgrade for systems running RDS/TCP or performing frequent pskb_carve operations
  • Monitor drop_monitor and kernel logs for skbuff BUG messages referencing stale mac_header values
  • Test the patched kernel in a staging environment with RDS workloads before production rollout

The record

In the Linux kernel, the following vulnerability has been resolved: net: skbuff: do not leave stale header offsets after pskb_carve() pskb_carve_inside_header() and pskb_carve_inside_nonlinear() remove the first bytes of a packet and reallocate skb->head. All the headers that were present before the operation are gone, but both functions call skb_headers_offset_update(skb, 0), which is a no-op : skb->mac_header, skb->network_header, skb->transport_header and skb->csum_start keep their old values and now describe bytes which are no longer there. Both helpers size the new head from the old skb_end_offset(), so the stale offsets still land inside the new allocation. They point past skb_tail_pointer() though, to bytes that were never initialized. pskb_carve_inside_nonlinear() is the worst case, because it leaves a zombie skb with an empty linear part (skb->data == skb_tail_pointer(skb), skb_headlen(skb) == 0), while skb_mac_header_was_set() is still true and skb->mac_header is way ahead of skb->data. The only user of pskb_extract() is rds_tcp_data_recv(), and the carved skb is queued on tinc->ti_skb_list. When the RDS incoming message is released, rds_tcp_inc_free() calls skb_queue_purge(), which frees the skbs with SKB_DROP_REASON_QUEUE_PURGE. This is visible from drop_monitor, which then tries to pull back to the (bogus) mac header : skbuff: __skb_pull(len=234) skb len=6968 data_len=6968 headroom=0 headlen=0 tailroom=0 end-tail=384 mac=(234,14) mac_len=14 net=(248,40) trans=288 shinfo(txflags=0 nr_frags=1 gso(size=1428 type=16 segs=5)) csum(0x100120 start=288 offset=16 ip_summed=3 complete_sw=0 valid=1 level=0) hash(0x7b446c6c sw=0 l4=1) proto=0x86dd pkttype=0 iif=60 kernel BUG at ./include/linux/skbuff.h:2847! Add skb_carve_reset_headers() to mark the mac and transport headers as not set, reset the network header, clear skb->mac_len, and drop a now meaningless CHECKSUM_PARTIAL (csum_start no longer describes anything). Invalidate the inner offsets as well. Unlike mac_header and transport_header they have no "unset" sentinel, so a leftover non-zero value still looks like a real header. Zero skb->inner_mac_header, skb->inner_network_header, skb->inner_transport_header, skb->inner_protocol and skb->encapsulation, so that all the header state is invalidated in one place. v2: fixed an inaccurate changelog. The stale offsets stay inside the new skb->head, which is never smaller than the old one, they simply point past skb_tail_pointer() to bytes that are gone. Thanks to Xuanqiang Luo for insisting on this. Also invalidate the inner header state, as suggested by the netdev AI review : https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260911114922.621937-1-edumazet%40google.com

Affected packages

Ecosystem Package Introduced Fixed