CVE-2026-98271

UNRATEDCVSS · not yet scoredTrending — 4 sources updated this week
—
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: 0.2%CVSS v2: —Exploit: None knownExposed services: Not assessed

A fix is available — apply it.

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

CVSS v3
—
EchelonGraph score
Not yet assessedNo source has published severity data for this CVE yet — no CVSS score from NVD or a CNA, no GitHub advisory, and it is not in CISA KEV. This is not a rating of zero; we cannot assess it yet.
EG Score
—
EG Risk
—
EPSS PROB
0.2%
EPSS %ILE
6th
KEV
Not listed

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

October 6, 2026

Last Modified

October 6, 2026

References (4)

Vendor Advisories for CVE-2026-98271(2)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(3 across 3 ecosystems)
Debian:12(1)
PackageVulnerable rangeFix by version rangeDependents
linux6.1.106-1 ... 7.2~rc7-1~exp1 (360 versions)
  • every version on: no fix on record
—
Debian:13(1)
PackageVulnerable rangeFix by version rangeDependents
linux6.12.100-1 ... 7.2~rc7-1~exp1 (183 versions)
  • every version on: no fix on record
—
Debian:14(1)
PackageVulnerable rangeFix by version rangeDependents
linux6.12.100-1 ... 7.2~rc7-1~exp1 (181 versions)
  • every version up to 7.2.8-1: fixed in 7.2.8-1
—

Data Freshness Timeline

(refreshed 14× in last 7d / 19× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. An arrow marks a change the record states ("CVSS v3 → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). Most recent first.

  1. 2026-10-13 16:35 UTCEPSS rescoreEPSS 0.2% · 6th percentile
  2. 2026-10-12 16:35 UTCEPSS rescoreEPSS 0.2% · 6th percentile
  3. 2026-10-12 14:38 UTCEG score recompute
  4. 2026-10-11 19:10 UTCEG score recompute
  5. 2026-10-11 16:25 UTCEG score recompute
  6. 2026-10-11 13:50 UTCEPSS rescoreEPSS 0.2% · 6th percentile
  7. 2026-10-11 13:37 UTCEG score recompute
  8. 2026-10-10 20:00 UTCEPSS rescoreEPSS 0.2% · 6th percentile
  9. 2026-10-09 20:08 UTCEPSS rescoreEPSS 0.2% · 6th percentile
  10. 2026-10-09 08:51 UTCEG score recompute
  11. 2026-10-09 08:51 UTCVendor advisory
  12. 2026-10-09 08:51 UTCGHSA enrichmentGHSA-p44r-ff57-rwr9
  13. 2026-10-08 17:14 UTCEPSS rescoreEPSS 0.2% · 6th percentile
  14. 2026-10-07 23:48 UTCEPSS rescoreEPSS 0.2% · 6th percentile
  15. 2026-10-06 15:19 UTCEPSS rescoreEPSS 0.2% · 6th percentile
  16. 2026-10-06 09:41 UTCGHSA enrichmentGHSA-p44r-ff57-rwr9
  17. 2026-10-06 09:28 UTCNVD update
  18. 2026-10-06 08:54 UTCEG score recompute
  19. 2026-10-06 08:52 UTCMITRE cvelistV5first tracked

Frequently asked(4)

What is CVE-2026-98271?
CVE-2026-98271 is a vulnerability whose severity is not yet rated; its CVE record was published on October 6, 2026. In the Linux kernel, the following vulnerability has been resolved: net: skbuff: do not leave stale header offsets after pskb_carve() pskbcarveinsideheader() and pskbcarveinsidenonlinear() remove the first bytes of a packet and reallocate skb->head. All the headers that were present before the…
When was the CVE record for CVE-2026-98271 published?
The CVE record for CVE-2026-98271 was published on October 6, 2026. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of October 6, 2026; the record at its source may have been updated since.
Is CVE-2026-98271 actively exploited?
CVE-2026-98271 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.2% probability of exploitation in the next 30 days (6th percentile of EPSS-scored CVEs).
How do I remediate CVE-2026-98271?
A fix for CVE-2026-98271 is available: update to the fixed version the vendor names in its advisory. The vendor advisories EchelonGraph has for CVE-2026-98271 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-98271

Explore →

Is Your Infrastructure Affected by CVE-2026-98271?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.

Book a Demo →Browse All CVEs