CVE-2026-98271: net: skbuff: do not leave stale header offsets after pskb_carve()
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: do not leave stale header offsets after pskbcarve()
pskbcarveinsideheader() and pskbcarveinsidenonlinear() 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 skbheadersoffsetupdate(skb, 0), which is a no-op : skb->macheader, skb->networkheader, skb->transportheader and skb->csumstart keep their old values and now describe bytes which are no longer there.
Both helpers size the new head from the old skbendoffset(), so the stale offsets still land inside the new allocation. They point past skbtailpointer() though, to bytes that were never initialized.
pskbcarveinsidenonlinear() is the worst case, because it leaves a zombie skb with an empty linear part (skb->data == skbtailpointer(skb), skbheadlen(skb) == 0), while skbmacheaderwasset() is still true and skb->macheader is way ahead of skb->data.
The only user of pskbextract() is rdstcpdatarecv(), and the carved skb is queued on tinc->tiskblist. When the RDS incoming message is released, rdstcpincfree() calls skbqueuepurge(), which frees the skbs with SKBDROPREASONQUEUEPURGE. This is visible from dropmonitor, which then tries to pull back to the (bogus) mac header :
skbuff: skbpull(len=234) skb len=6968 datalen=6968 headroom=0 headlen=0 tailroom=0 end-tail=384 mac=(234,14) maclen=14 net=(248,40) trans=288 shinfo(txflags=0 nrfrags=1 gso(size=1428 type=16 segs=5)) csum(0x100120 start=288 offset=16 ipsummed=3 completesw=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 skbcarveresetheaders() to mark the mac and transport headers as not set, reset the network header, clear skb->maclen, and drop a now meaningless CHECKSUMPARTIAL (csumstart no longer describes anything).
Invalidate the inner offsets as well. Unlike macheader and transportheader they have no "unset" sentinel, so a leftover non-zero value still looks like a real header. Zero skb->innermacheader, skb->innernetworkheader, skb->innertransportheader, skb->innerprotocol 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 skbtailpointer() 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 Software
Event History
Frequently Asked Questions
Which runtime path is implicated by the available details?
The only stated user of pskb_extract() is rds_tcp_data_recv(). That path queues the carved socket buffer on tinc->ti_skb_list for incoming RDS messages.
What condition appears necessary for the affected code to be reached?
The available data indicates that RDS TCP receive processing must invoke rds_tcp_data_recv(), which in turn is the stated sole user of pskb_extract(). No information is provided about default RDS configuration or network exposure.
Why is the nonlinear carve path considered the most severe case?
pskb_carve_inside_nonlinear() can leave a socket buffer with an empty linear portion while its MAC-header state remains set and its MAC-header offset points ahead of the packet data. The stale offsets can point to allocated but uninitialized bytes beyond the tail pointer.