In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition…
CVE-2026-72322 · published 15 Aug 2026
How serious is it
- Severity: critical, CVSS score 9.8 out of 10.
- No exploit prediction (EPSS) score yet.
- Not on the CISA list of exploited vulnerabilities.
- No public exploit in Exploit-DB.
Is your app affected by CVE-2026-72322?
Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.
Who is affected
- Linux Linux: 2.6.12
How to check
- Find out whether you run the affected product and which version, then compare it with the versions above.
How to fix
Copies a prompt for Claude Code, Cursor or Codex that asks it to check whether you run this product.
- Apply the vendor's update or mitigation from the references below. If there is none yet, limit exposure of the affected service until there is.
- If a vulnerable version was live, check your logs and rotate the secrets that server could read.
The advisory
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: Fix potential UAF in MLD delayed work
A race condition exists between device teardown and incoming MLD query
processing, leading to a Use-After-Free in the MLD delayed work.
During device destruction, the primary reference to inet6_dev is dropped,
which can drop its refcount to 0. The actual freeing of inet6_dev memory
is deferred via RCU.
Concurrently, the packet receive path runs under RCU read lock and obtains
the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can
safely dereference inet6_dev even if its refcount has hit 0.
However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it
attempts to acquire a reference using in6_dev_hold(). This increments the
refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning.
Since the inet6_dev memory is still scheduled to be freed after the RCU
grace period, the device is freed while the work is still scheduled.
When the work runs, it accesses the freed memory, causing a kernel panic.
Fix this by using refcount_inc_not_zero() (via a new helper
in6_dev_hold_safe()) to prevent acquiring a reference if the device is
already being destroyed. If the refcount is 0, we do not schedule the work.
Check your whole app
Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.
References
- git.kernel.org/stable/c/0401d6cf7877c9be36652385dfcbf7f891b8b590
- git.kernel.org/stable/c/0458ba1cda830ba4ccfcd9e19c0891438bcdbe4e
- git.kernel.org/stable/c/9815e834f5ff8b39e0ea9f0dbd532f4a3b8f0785
- git.kernel.org/stable/c/9b26518b6896a16b809b1e42986f4ebac7bccc1e
- git.kernel.org/stable/c/9ce741c22df4fd9546e30306317ac7df3607e48f
- git.kernel.org/stable/c/ebbebf6cee950d7f1c81990256c0eae9e62572ae
- git.kernel.org/stable/c/f03b0a45535d49bdab7e502efaacee205b2a7865
- git.kernel.org/stable/c/f12b63ef26a035c5a29b3ef56401e38199010d4a
Merged from NVD. Last updated 23 Oct 2026. All vulnerabilities · RSS · JSON