CVE-2026-72120 is an RCU list synchronization bug in the Linux kernel's CAN BCM (Broadcast Manager) subsystem. The vulnerability arises from using list_add() and list_del() instead of their RCU-safe counterparts list_add_rcu() and list_del_rcu() in the bcm_rx_setup() path and related functions. This creates windows where RCU readers can observe partially-initialized structures during insertion or already-freed structures during deletion. The race only manifests under specific memory ordering and timing conditions, making it a heisenbug that would survive casual testing but could lead to use-after-free or NULL pointer dereference under concurrent load.
The critical exposure path runs through /proc/net/can-bcm, which is readable by any unprivileged userspace process. The bcm_proc_show() function traverses the affected lists under rcu_read_lock(), meaning triggering the race condition requires only local access to read a procfs file—not root or any special capability. While the EPSS score of 0.00164 suggests low near-term exploitability, RCU list bugs in network-adjacent subsystems have historically been chained with other local exploits for privilege escalation.
For defenders, the immediate priority is applying the vendor patch. Beyond that, audit any custom CAN BCM code for similar patterns: look for list_add() or list_del() calls on structures that are also traversed under RCU read-side locks elsewhere in the kernel. The invariant is strict—any list that might be read under rcu_read_lock() anywhere in the codebase must use *_rcu() variants exclusively. Check that insertion happens after full structure initialization and that deletion precedes the call_rcu() handoff.
The deeper problem this CVE exposes is systemic, not isolated. The kernel's list API provides safe and unsafe variants that are functionally identical under single-threaded execution and differ only in memory barrier behavior. There is no compiler warning, no static analysis flag, and no annotation that flags list_add() in an RCU-protected context as incorrect. The API makes the unsafe operation the frictionless default—it compiles cleanly, passes tests, and only fails under race conditions that won't appear in any unit test. This design choice means the constraint lives only in documentation and developer memory, not in the code itself. Subsystems touching CAN, netfilter, and virtual filesystems have all produced similar bugs independently, suggesting this is a recurring class that static analysis tooling or API redesign—not individual remediation—will ultimately prevent.