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 · 8/9 advisories · checked 00:13 UTC Customize Public modeDiscuss ChangeIntel on Discord

net: cap skb->queue_mapping when the tx queue is picked

Assessment

Severity
Moderate
CVSS base score
6.4CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
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
20 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
HighAC:H
Privileges required
HighPR:H
User interaction
NoneUI:N
Scope
UnchangedS:U
Confidentiality
HighC:H
Integrity
HighI:H
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 (38)

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:47 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:40 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 revised20 Oct 2026 01:04 UTC → 21 Oct 2026 18:40 UTC

Explore global source statements, affected packages and advisory history for CVE-2026-98797. 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-98797

Published

net: cap skb->queue_mapping when the tx queue is picked

In the Linux kernel, the following vulnerability has been resolved: net: cap skb->queue_mapping when the tx queue is picked skbedit can set skb->queue_mapping and raise the per-CPU skip_txqueue flag so __dev_queue_xmit() honours the mapping. __dev_queue_xmit() cleared the flag before sch_handle_egress() and only read it afterwards, so the flag was not confined to the xmit that set it: a nested xmit (mirred redirect or mirror, or a drop after skbedit) could set the flag and the outer xmit would consume it for an skb that never went through skbedit. A forwarded packet still carries the ingress NIC's rx_queue + 1 in skb->queue_mapping, so the outer device then indexes its tx queue state with that stale value. Taprio's child array q->qdiscs[] is sized to the device's queue count, so taprio_enqueue() indexes past its allocation and dereferences the result as a struct Qdisc *. We (ab)use the skb->nf_skip_egress which means "skip netfilter egress for this packet" to tag to "am I in tc egress?". Despite the overload I dont see it as a conflict since the marker is set only around the single sch_handle_egress() call and ingress path is guarded by tc_at_ingress. I will send a followup(net-next) patch once this hits net-next to rename the skb->nf_skip_egress bit/flag to skb->skip_egress Arm the flag only from the egress classifier that can use it: raise skip_txqueue from tcf_skbedit_act() only when it runs inside sch_handle_egress(), thanks to skb->nf_skip_egress. An egress qdisc classifier runs in q->enqueue(), after the tx queue has been picked, so a mapping it sets cannot affect the current packet; arming the flag there only pollutes it for a later xmit. Then own the flag for the xmit frame the egress hook runs in: save the incoming value and clear it just before sch_handle_egress(), and restore it after the hook - on the consumed (drop) path, or, in the same call that reads it, on the surviving path. The save and the restores stay inside the egress_needed_key static branch, so a packet pays for them only when egress hooks are active (2f1e85b1aee4). Store the value netdev_cap_txqueue() selected back into skb->queue_mapping in netdev_tx_queue_mapping(), as netdev_core_pick_tx() already does, so the skip_txqueue path never hands a later reader on the xmit path a mapping the device cannot serve. A store made still later in the same frame, by a tc BPF program attached to a transmit qdisc, is outside this path and is not re-capped; a separate followup will resolve that path. netdev_xmit_skip_txqueue() returns the previous flag value so the save-and-clear is one call, and a no-op stub is provided when CONFIG_NET_EGRESS is disabled. skb->nf_skip_egress is compiled under CONFIG_NET_EGRESS rather than CONFIG_NETFILTER_SKIP_EGRESS, so skb_at_tc_egress() is valid whenever the egress path is built. A local user in a network namespace can redirect a packet from a device with more TX queues to one with fewer after setting a mapping valid only on the larger device. That reaches these reads and, under KASAN, faults with "slab-out-of-bounds in taprio_enqueue". Conditions to recreate the bug: the report's own trigger is a local user with CAP_NET_ADMIN in a network namespace, so no eBPF program is needed. With CONFIG_NET_SCH_TAPRIO=y, CONFIG_NET_ACT_SKBEDIT=y, CONFIG_NET_ACT_MIRRED=y, CONFIG_NET_CLS_MATCHALL=y, CONFIG_NET_SCH_PRIO=y and KASAN enabled, create qa (3 queues), qb (2 queues) and qc (1 queue) as dummy devices; put a taprio root on qb (num_tc 1, queues 2@0) and clsact on all three; then add an egress matchall filter on every device. On qa: "action skbedit queue_mapping 2 pipe action mirred egress redirect dev qb". On qb: "action mirred egress mirror dev qc". On qc: "action skbedit queue_mapping 0 pipe". Send one packet out qa. qc's skbedit sets the flag while qb's outer xmit is in flight; without the fix qb consumes it and reads its two-entry taprio child array with the forwarded packet's stale mapping. A qc whose skb ---truncated---

Source published
18 Oct 2026 15:48:41 UTC
Source modified
19 Oct 2026 09:25:49 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 00:13 UTC · 275 of 275 readable · 273 fully read · documentation 469/469 current