Linux Kernel up to 6.12.111/6.18.53/7.2.7/7.3-rc3 skbuff /include/linux/skbuff.h pskb_carve_inside_header initialization

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 7.0 | $0-$5k | 0.30- |
Summary
A vulnerability labeled as critical has been found in Linux Kernel up to 6.12.111/6.18.53/7.2.7/7.3-rc3. Affected by this vulnerability is the function pskb_carve_inside_header of the file /include/linux/skbuff.h of the component skbuff. The manipulation of the argument mac_header/network_header/transport_header/csum_start results in initialization.
This vulnerability was named CVE-2026-98271. The attack may be performed from remote. There is no available exploit.
The affected component should be upgraded.
Details
A vulnerability classified as critical has been found in Linux Kernel up to 6.12.111/6.18.53/7.2.7/7.3-rc3. Affected is the function pskb_carve_inside_header of the file /include/linux/skbuff.h of the component skbuff. The manipulation of the argument mac_header/network_header/transport_header/csum_start with an unknown input leads to a initialization vulnerability. CWE is classifying the issue as CWE-665. The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used. This is going to have an impact on confidentiality, integrity, and availability. CVE summarizes:
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
The advisory is available at git.kernel.org. This vulnerability is traded as CVE-2026-98271 since 09/25/2026. The exploitability is told to be easy. It is possible to launch the attack remotely. The exploitation doesn't require any form of authentication. Technical details are known, but there is no available exploit. The structure of the vulnerability defines a possible price range of USD $0-$5k at the moment (estimation calculated on 10/06/2026).
Upgrading to version 6.12.112, 6.18.54, 7.2.8 or 7.3-rc4 eliminates this vulnerability. Applying the patch 75e4a3e62531738c124c8555a626426fca29d392/bff8a8e53a6d290bc2777bde36d3cb6317b8463d/12929ed66a5166177ef5f06d3da81e4f99993e90/a5117e1eccac6ee3bd4aed7cacf8ebcb6b3eb309 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Product
Type
Vendor
Name
Version
- 6.12.111
- 6.18.0
- 6.18.1
- 6.18.2
- 6.18.3
- 6.18.4
- 6.18.5
- 6.18.6
- 6.18.7
- 6.18.8
- 6.18.9
- 6.18.10
- 6.18.11
- 6.18.12
- 6.18.13
- 6.18.14
- 6.18.15
- 6.18.16
- 6.18.17
- 6.18.18
- 6.18.19
- 6.18.20
- 6.18.21
- 6.18.22
- 6.18.23
- 6.18.24
- 6.18.25
- 6.18.26
- 6.18.27
- 6.18.28
- 6.18.29
- 6.18.30
- 6.18.31
- 6.18.32
- 6.18.33
- 6.18.34
- 6.18.35
- 6.18.36
- 6.18.37
- 6.18.38
- 6.18.39
- 6.18.40
- 6.18.41
- 6.18.42
- 6.18.43
- 6.18.44
- 6.18.45
- 6.18.46
- 6.18.47
- 6.18.48
- 6.18.49
- 6.18.50
- 6.18.51
- 6.18.52
- 6.18.53
- 7.2.0
- 7.2.1
- 7.2.2
- 7.2.3
- 7.2.4
- 7.2.5
- 7.2.6
- 7.2.7
- 7.3-rc1
- 7.3-rc2
- 7.3-rc3
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 7.3VulDB Meta Temp Score: 7.0
VulDB Base Score: 7.3
VulDB Temp Score: 7.0
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: InitializationCWE: CWE-665
CAPEC: 🔒
ATT&CK: 🔒
Physical: No
Local: No
Remote: Yes
Availability: 🔒
Status: Not defined
EPSS Score: 🔒
EPSS Percentile: 🔒
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 6.12.112/6.18.54/7.2.8/7.3-rc4
Patch: 75e4a3e62531738c124c8555a626426fca29d392/bff8a8e53a6d290bc2777bde36d3cb6317b8463d/12929ed66a5166177ef5f06d3da81e4f99993e90/a5117e1eccac6ee3bd4aed7cacf8ebcb6b3eb309
Timeline
09/25/2026 CVE reserved10/06/2026 Advisory disclosed
10/06/2026 VulDB entry created
10/06/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2026-98271 (🔒)
GCVE (CVE): GCVE-0-2026-98271
GCVE (VulDB): GCVE-100-414018
Entry
Created: 10/06/2026 12:04Changes: 10/06/2026 12:04 (61)
Complete: 🔍
Cache ID: 216::103
If you want to get best quality of vulnerability data, you may have to visit VulDB.
No comments yet. Languages: en.
Please log in to comment.