CVE-2026-98797: net: cap skb->queue_mapping when the tx queue is picked
Noroxi assessment
Priority: Monitor (action score 0/100)
- The sources we track (CISA KEV, Exploit-DB, Metasploit, Nuclei, GitHub) show no public exploit code or exploitation in the wild.
- Probability of exploitation in the next 30 days: 0.16% (FIRST EPSS).
- Fixed version: Linux Linux 2f581814e4e3ea6a5e98f49813dc4c68444a0c4a, c6ec35c8267c84c2094cb485db20c06384fc2bcc, ea4d4b5dddb5121e64f56fd8e0720bd8b447b63d; azl3 kernel 6.6.157.1-1 on Azure Linux 3.0 Release Notes; azl3 kernel 6.6.159.1-1 on Azure Linux 3.0 Release Notes.
Low priority for now. Upgrade to Linux Linux 2f581814e4e3ea6a5e98f49813dc4c68444a0c4a, c6ec35c8267c84c2094cb485db20c06384fc2bcc, ea4d4b5dddb5121e64f56fd8e0720bd8b447b63d; azl3 kernel 6.6.157.1-1 on Azure Linux 3.0 Release Notes; azl3 kernel 6.6.159.1-1 on Azure Linux 3.0 Release Notes or later.
Generated automatically from the record's data: CVSS (NVD and CNA), CISA KEV and SSVC, FIRST EPSS, exploit sources, fixed versions. How we calculate it
Primary sources: NVD · CVE.org · FIRST EPSS
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---
- Published
- Oct 18, 2026
- Updated
- Oct 19, 2026
- EPSS
- 0.1% · 5th percentile
- CWE
- —
Report tools
Action score
0
Monitor
Low priority for now.
- CVSS
- 0 / 40 · —
- CISA KEV
- 0 / 30 · Not listed
- EPSS
- 0 / 30 · 0.1%
Get told when this record changes
- Not in KEV: no record of exploitation in the wild
- No public exploit code on record
- A fix has been released
If any of these changes, we'll tell you in the daily email digest.
Running WordPress? Scan your site free with WP Lens
Noroxi analysis
What does it mean in your environment?
The assessment above is generated automatically from the record's data; it doesn't know your environment. Our team verifies on your systems whether this vulnerability is actually exploitable and which mitigation is enough.
We use this product, ask for helpAffected systems
Is your version affected?
Pick the product and type the version you run. It's compared with this record's version ranges in your browser; the version isn't sent anywhere.
—
Versions reported by the vendor
Affected version ranges reported by the assigning authority (Linux). Independent of NVD's CPE analysis and usually ahead of it.
Linux Linux
- 5.19affected
- 2f1e85b1aee459b7d0fd981839042c6a38ffaf0c and later · before c6ec35c8267c84c2094cb485db20c06384fc2bccaffected · git
- 2f1e85b1aee459b7d0fd981839042c6a38ffaf0c and later · before 2f581814e4e3ea6a5e98f49813dc4c68444a0c4aaffected · git
- 2f1e85b1aee459b7d0fd981839042c6a38ffaf0c and later · before f99de42f5c6f8d088063817dad82c3334e87c570affected · git
- 2f1e85b1aee459b7d0fd981839042c6a38ffaf0c and later · before ea4d4b5dddb5121e64f56fd8e0720bd8b447b63daffected · git
- before 5.19not affected · semver
- 6.12.113 and later · up to and including 6.12.*not affected · semver
- 6.18.56 and later · up to and including 6.18.*not affected · semver
- 7.2.10 and later · up to and including 7.2.*not affected · semver
- 7.3 and laternot affected · original_commit_for_fix
Package-level exposure
OSV and GitHub Advisory data: ecosystem, package and range. SBOM matching uses this table.
| Ecosystem | Package | Affected range | Fix |
|---|---|---|---|
| Debian:12 | linux | from 0 | — |
| Debian:12 | linux-6.12 | before 6.12.113-1~deb12u1 | 6.12.113-1~deb12u1 |
| Debian:13 | linux | before 6.12.113-1 | 6.12.113-1 |
| Debian:14 | linux | before 7.2.10-1 | 7.2.10-1 |
Same product
linux: all recordsOther highest-scoring records for the same primary product.
- CVE-2026-74705udp: fix potential use-after-free in tunnel segmentation40Plan
- CVE-2026-74612veth: fix skb length accounting after XDP frag adjustment40Plan
- CVE-2026-74475vxlan: use neigh_ha_snapshot() in route_shortcircuit()40Plan
Published before and after this one in the same product
- ← EarlierCVE-2026-98795Oct 18, 2026 · net: sparx5: skip ptp deinit if init was skipped0Monitor
- ← EarlierCVE-2026-98796Oct 18, 2026 · net: ethernet: mtk_eth_soc: allocate dummy netdev sooner0Monitor
- Later →CVE-2026-98798Oct 18, 2026 · net: bcmgenet: fix NULL dereference in set_coalesce before first open0Monitor
Remediation
Which version to upgrade to
Fix versions compiled from the vendor, package registries and Microsoft. Verify the vendor's note before upgrading.
| Product / package | Fixed version | Source |
|---|---|---|
| Linux Linux | 2f581814e4e3ea6a5e98f49813dc4c68444a0c4a | Vendor (CNA) |
| Linux Linux | c6ec35c8267c84c2094cb485db20c06384fc2bcc | Vendor (CNA) |
| Linux Linux | ea4d4b5dddb5121e64f56fd8e0720bd8b447b63d | Vendor (CNA) |
| Linux Linux | f99de42f5c6f8d088063817dad82c3334e87c570 | Vendor (CNA) |
| azl3 kernel 6.6.157.1-1 on Azure Linux 3.0 | Release Notes | Microsoft (MSRC) |
| azl3 kernel 6.6.159.1-1 on Azure Linux 3.0 | Release Notes | Microsoft (MSRC) |
| debian:linux | 6.12.113-1 · Debian:13 | Package registry (OSV) |
| debian:linux-6.12 | 6.12.113-1~deb12u1 · Debian:12 | Package registry (OSV) |
Exploit status
No known public exploit
No public exploit has been observed yet. That doesn't mean you're safe, only that the bar is a little higher.
Research context
For pentesters and researchers: attack profile, score disagreement, timeline, patch commits, credits, variant and chain candidates, bug bounty scope. All derived from existing data; no exploit code.
Timeline
From publication to today: proof of concept, Metasploit module, CISA KEV and fix record. Dates are as reported by the sources.
- Published
- Fix recordedsame day
- TodayNov 6, 2026+19 d
FIRST EPSS daily score; only changes of 0.01 or more are recorded (step chart).
Patch and commit links
Commit, PR and diff links among the references. A starting point for patch-diffing and variant hunting; fixes, not exploits.
No commit or PR link among the references.
Credits
All researchersFinders, reporters and analysts named in the CNA record. Click a name for that researcher’s other records.
No credits in the CNA record.
Variant candidates
Same product, same weakness class, within 18 months. If the patch missed the root cause, the sibling bug is here.
No nightly-computed relations.
Chain candidates
An authentication bypass and a privilege-requiring bug in the same product, published close together: combined they may become an unauthenticated path.
—
Bug bounty scope
No known public program.
Source: bounty-targets-data (public HackerOne, Bugcrowd, Intigriti, YesWeHack listings).
Technical details
No CVSS vector for this record, so attack conditions can't be derived.
Weakness class (CWE)
—
Attack context
MITRE CAPEC attack patterns and ATT&CK techniques for this weakness class (CWE). A starting point for detection rules and threat hunting.
MITRE has no CAPEC/ATT&CK mapping for this CWE.
Change log
- Exploit maturity— → none
- Fix✗ → ✓
For records you follow, these changes also arrive as notifications. →
References
Show all references (3 more)Show less
Vendor advisories and official records. Exploit/PoC links are deliberately left out.