net: serialize netif_running() check in enqueue_to_backlog()
CVE-2026-72493 · published 15 Aug 2026
How serious is it
- Severity: critical, CVSS score 9.9 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-72493?
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: e9e4dd3267d0c5234c5c0f47440456b10875dec9 to < cbe10ea090ea9d6fa5ff50c9b44f2a86fe56f0b7, e9e4dd3267d0c5234c5c0f47440456b10875dec9 to < b422e3eff0edf0975de4883929adbed28f9d08bc, e9e4dd3267d0c5234c5c0f47440456b10875dec9 to < 2fface6e0bbd6314d1d9d071abf2c4d67548511c, e9e4dd3267d0c5234c5c0f47440456b10875dec9 to < 46762cefe7f4e5bffc1eb467810a7bbb02e461d7
- Linux Linux: 4.2
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:
net: serialize netif_running() check in enqueue_to_backlog()
Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup().
The root cause is a race condition where packets can escape the backlog
flushing during device unregistration (e.g., during netns exit).
Commit e9e4dd3267d0 ("net: do not process device backlog during unregistration")
introduced a lockless netif_running() check in enqueue_to_backlog() to
prevent queuing packets to an unregistering device.
However, this creates a TOCTOU race window.
A lockless transmitter (like veth_xmit) can pass
the check before dev_close() clears IFF_UP. If the transmitter is then
delayed, flush_all_backlogs() can run and finish before the transmitter
grabs the backlog lock and queues the packet. The packet then escapes
the flush and triggers UAF later when processed.
Fix this by moving the netif_running() check inside the backlog lock.
This serializes the check with the flush work (which also grabs the lock).
We then either queue the packet before the flush runs (so it gets flushed),
or check netif_running() after the flush/close completes (so it gets dropped).
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/cbe10ea090ea9d6fa5ff50c9b44f2a86fe56f0b7
- git.kernel.org/stable/c/b422e3eff0edf0975de4883929adbed28f9d08bc
- git.kernel.org/stable/c/2fface6e0bbd6314d1d9d071abf2c4d67548511c
- git.kernel.org/stable/c/46762cefe7f4e5bffc1eb467810a7bbb02e461d7
Merged from CVE List. Last updated 25 Oct 2026. All vulnerabilities · RSS · JSON