Public mode

No access to your tenant or devices. Every item links to its source. What this means

Some sources, documents or advisories need attention: 275/275 feeds/APIs · 469/469 docs · 7/9 advisories · checked 01:18 UTC Customize Public modeDiscuss ChangeIntel on Discord

net: skbuff: do not leave stale header offsets after pskb_carve()

Assessment

Severity
Moderate
CVSS base score
6.1CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H/E:U
Impact
Not stated
EPSS · 30-day forecast
No EPSS score collected
Public detection template
No Nuclei template is listed in the current collected catalog
Exploitation detected
Unknown: not stated by MSRC
Exploitability
Not assessed
Publicly disclosed
Unknown: not stated by MSRC
Customer action
Required: follow the MSRC remediation guidance
Component
Mariner
Weakness
—
Issued by
Linux
Published
7 Oct 2026 · October 2026
Last revised
5 Nov 2026Information published.
CVSS 3.1 base metricsRed raises the risk · green lowers it
Attack vector
LocalAV:L
Attack complexity
LowAC:L
Privileges required
LowPR:L
User interaction
NoneUI:N
Scope
UnchangedS:U
Confidentiality
NoneC:N
Integrity
LowI:L
Availability
HighA:H

Updates that fix it

0 KBs

No KB listed

No KB update is listed in the collected MSRC record. Check the MSRC advisory for product releases and other remedies.

Affected products

Open Source Software
3 affected products
  • azl3 kernel 6.6.157.1-1 on Azure Linux 3.0
  • azl3 kernel 6.6.159.1-1 on Azure Linux 3.0
  • azl3 kernel 6.6.161.1-1 on Azure Linux 3.0

What changed

  1. Detection template: Unknown: detection-template evidence is incomplete or retained → No Nuclei template listed
  2. Detection template: No Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
  3. Affected products: azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0 → azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0, azl3 kernel 6.6.161.1-1 on Azure Linux 3.0
  4. Detection template: Unknown: detection-template evidence is incomplete or retained → No Nuclei template listed
  5. Detection template: No Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
  6. Affected products: azl3 kernel 6.6.157.1-1 on Azure Linux 3.0 → azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0
  7. Detection template: No Nuclei template listed · Customer action: Required: apply the update → Required: follow the MSRC remediation guidance · Public disclosure: No → Unknown: not stated by MSRC · Exploitation detected: Not reported by MSRC → Unknown: not stated by MSRC
  8. Detection template: Unknown: exploit-code evidence is incomplete or retained → No Nuclei template listed · CISA KEV: Unknown: catalog evidence is incomplete or retained → Not listed in the collected catalog
  9. Detection template: No Nuclei template listed → Unknown: exploit-code evidence is incomplete or retained · CISA KEV: Not listed in the collected catalog → Unknown: catalog evidence is incomplete or retained
Page history

Changes are dated when recorded; day views use the last saved version from that UTC day, and citations stay fixed.

Cite this version
Field-level log (40)

Up to 100 recent field edits are shown; older edits may be outside retention.

  1. 6 Nov 2026 · 17:32:22 UTC Public detection templateUnknown: detection-template evidence is incomplete or retained → No Nuclei template listed
  2. 6 Nov 2026 · 17:32:22 UTC Source coverage: public-exploit-codeIncomplete → Current
  3. 6 Nov 2026 · 17:32:22 UTC Source coverage: first-epssIncomplete → Current
  4. 6 Nov 2026 · 17:32:22 UTC Source coverage: msrc-cvrfIncomplete → Current
  5. 6 Nov 2026 · 16:31:02 UTC Public detection templateNo Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
  6. 6 Nov 2026 · 16:31:02 UTC Source coverage: public-exploit-codeCurrent → Incomplete
  7. 6 Nov 2026 · 16:31:02 UTC Source coverage: first-epssCurrent → Incomplete
  8. 6 Nov 2026 · 16:31:02 UTC Source coverage: msrc-cvrfCurrent → Incomplete
  9. 6 Nov 2026 · 09:07:49 UTC Last revised1 Nov 2026 14:48 UTC → 5 Nov 2026 14:56 UTC
  10. 6 Nov 2026 · 09:07:49 UTC Affected productsazl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0 → azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0, azl3 kernel 6.6.161.1-1 on Azure Linux 3.0
  11. 2 Nov 2026 · 17:30:39 UTC Public detection templateUnknown: detection-template evidence is incomplete or retained → No Nuclei template listed
  12. 2 Nov 2026 · 17:30:39 UTC Source coverage: public-exploit-codeIncomplete → Current
  13. 2 Nov 2026 · 17:30:39 UTC Source coverage: first-epssIncomplete → Current
  14. 2 Nov 2026 · 17:30:39 UTC Source coverage: msrc-cvrfIncomplete → Current
  15. 2 Nov 2026 · 16:27:39 UTC Public detection templateNo Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
  16. 2 Nov 2026 · 16:27:39 UTC Source coverage: public-exploit-codeCurrent → Incomplete
  17. 2 Nov 2026 · 16:27:39 UTC Source coverage: first-epssCurrent → Incomplete
  18. 2 Nov 2026 · 16:27:39 UTC Source coverage: msrc-cvrfCurrent → Incomplete
  19. 2 Nov 2026 · 09:04:36 UTC Last revised21 Oct 2026 18:35 UTC → 1 Nov 2026 14:48 UTC
  20. 2 Nov 2026 · 09:04:36 UTC Affected productsazl3 kernel 6.6.157.1-1 on Azure Linux 3.0 → azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0
  21. 29 Oct 2026 · 20:19:26 UTC Public detection templateNo Nuclei template listed
  22. 29 Oct 2026 · 20:19:26 UTC EPSSNot scored → No EPSS score collected
  23. 29 Oct 2026 · 20:19:26 UTC Customer actionRequired: apply the update → Required: follow the MSRC remediation guidance
  24. 29 Oct 2026 · 20:19:26 UTC Publicly disclosedNo → Unknown: not stated by MSRC
  25. 29 Oct 2026 · 20:19:26 UTC Exploitation detectedNot reported by MSRC → Unknown: not stated by MSRC
  26. 23 Oct 2026 · 09:33:49 UTC Public exploit codeUnknown: exploit-code evidence is incomplete or retained → No Nuclei template listed
  27. 23 Oct 2026 · 09:33:49 UTC CISA KEVUnknown: catalog evidence is incomplete or retained → Not listed in the collected catalog
  28. 23 Oct 2026 · 09:33:49 UTC Source coverage: public-exploit-codeIncomplete → Current
  29. 23 Oct 2026 · 09:33:49 UTC Source coverage: first-epssIncomplete → Current
  30. 23 Oct 2026 · 09:33:49 UTC Source coverage: cisa-kevIncomplete → Current
  31. 23 Oct 2026 · 09:33:49 UTC Source coverage: msrc-cvrfIncomplete → Current
  32. 23 Oct 2026 · 08:31:50 UTC Public exploit codeNo Nuclei template listed → Unknown: exploit-code evidence is incomplete or retained
  33. 23 Oct 2026 · 08:31:50 UTC CISA KEVNot listed in the collected catalog → Unknown: catalog evidence is incomplete or retained
  34. 23 Oct 2026 · 08:31:50 UTC Source coverage: public-exploit-codeCurrent → Incomplete
  35. 23 Oct 2026 · 08:31:50 UTC Source coverage: first-epssCurrent → Incomplete
  36. 23 Oct 2026 · 08:31:50 UTC Source coverage: cisa-kevCurrent → Incomplete
  37. 23 Oct 2026 · 08:31:50 UTC Source coverage: msrc-cvrfCurrent → Incomplete
  38. 21 Oct 2026 · 20:45:25 UTC Last revised7 Oct 2026 01:15 UTC → 21 Oct 2026 18:35 UTC
  39. 18 Oct 2026 · 14:54:30 UTC Link: October 2026/security?release=2026-Oct#cves
  40. 14 Oct 2026 · 11:22:42 UTC Source coverage: msrc-cvrfIncomplete → Current

Explore global source statements, affected packages and advisory history for CVE-2026-98271. The catalog has a separate collection scope from Microsoft release records.

Collected exploitation and prediction evidence

Risk source coverage

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

cve-program · CVE-2026-98271

Published

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 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

Source published
6 Oct 2026 08:45:33 UTC
Source modified
19 Oct 2026 09:16:41 UTC
Observed here
23 Oct 2026 15:48:27 UTC
Source terms
CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 9 Nov 01:18 UTC · 275 of 275 readable · 272 fully read · documentation 469/469 current