Answer in brief
CVE-2026-98968 records a High severity (CVSS 8.1) vulnerability in amt: send the relay's General Query directly from the receive path. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.1. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=cbc21dc1cfe949e37b2a54c71511579f1899e8d4 <95114e421196250e3d9662f12df442799477d3c3 || >=cbc21dc1cfe949e37b2a54c71511579f1899e8d4 <e7183b7d518ce8b3e1f7284f9881d7a87569df14 || >=cbc21dc1cfe949e37b2a54c71511579f1899e8d4 <181cb48c1e9af6b402567e132f879f89d1c54131 || >=cbc21dc1cfe949e37b2a54c71511579f1899e8d4 <e7ea63b4195a150604993044ab574d8240f2a399 || >=cbc21dc1cfe949e37b2a54c71511579f1899e8d4 <afae89de73dd693cfa329580ba0fba63bd3f0a11 | 95114e421196250e3d9662f12df442799477d3c3, e7183b7d518ce8b3e1f7284f9881d7a87569df14, 181cb48c1e9af6b402567e132f879f89d1c54131, e7ea63b4195a150604993044ab574d8240f2a399, afae89de73dd693cfa329580ba0fba63bd3f0a11 |
| Linux/Linuxgeneric | 5.16 | Not reported |
Published upstream
Oct 23, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 23, 2026
In the Linux kernel, the following vulnerability has been resolved: amt: send the relay's General Query directly from the receive path An skb queued in a qdisc can outlive the tunnel it references through a raw pointer in skb->cb. For example, with igmp_qrv set to 1 on the relay a tunnel lives for 135s, so a netem delay of 180s on the amt device outlives it; when the tunnel expires and is freed, the subsequent dequeue triggers a use-after-free in amt_dev_xmit(). BUG: KASAN: slab-use-after-free in amt_dev_xmit+0x2763/0x2e20 Call Trace: amt_dev_xmit+0x2763/0x2e20 [drivers/net/amt.c:1262] dev_hard_start_xmit+0x22f/0x620 sch_direct_xmit+0x12e/0xac0 netem_dequeue+0x333/0xc50 net_tx_action+0x35c/0xa60 amt_send_igmp_gq() and amt_send_mld_gq() are only called from amt_request_handler(), inside the rcu_read_lock_bh() section of amt_rcv(). amt_request_handler() already has the tunnel the query is for: it found or created it inside that section. Queuing the query with dev_queue_xmit() only leads back into amt_dev_xmit(), which strips the Ethernet header and calls amt_send_membership_query() for that tunnel. Make that call directly from the two senders instead, the same way amt_send_advertisement() transmits from the receive path. The query never waits in a qdisc, the tunnel is only dereferenced inside the RCU section that found or created it, and nothing is stored in skb->cb, so no lookup or refcount is needed. Remove the query branch of amt_dev_xmit(), amt_skb_cb() and struct amt_skb_cb, which have no users left. Behaviour changes: - The relay's own General Queries no longer pass through the amt device's egress path: its qdisc, tc egress (clsact/tcx), the netfilter egress hook and packet taps. They are still visible as UDP on the underlay. - A query that is sent successfully is no longer counted as tx_dropped. The old query branch left through the unlock label, which counted every sent query as dropped. - A query that reaches amt_dev_xmit() on a relay from elsewhere, such as a userspace querier, is now dropped at the IGMP/MLD type switch. Before, it trusted whatever skb->cb held, and a NULL tunnel hit the WARN_ON(1).
Quoted source text, attributed separately from HOL analysis.