CVE-2026-72120 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add missing rcu list annotations and operations
sashiko-bot remarked the missing use of list_add_rcu() in bcm_[rx|tx]_setup() to have a proper initialized bcm_op structure
when bcm_proc_show() traverses the bcm_op's under rcu_read_lock().
To cover all initial settings of the bcm_op's the list_add_rcu() calls are moved to the end of the setup code.
While at it, also fix the mirroring removal side: bcm_release() called bcm_remove_op() - which frees the op via call_rcu() - on ops that were still linked in bo->tx_ops/bo->rx_ops, without list_del_rcu() first. Unlink each op with list_del_rcu() before handing it to bcm_remove_op(), matching the existing pattern in bcm_delete_tx_op()/bcm_delete_rx_op().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's can subsystem, specifically in the broadcast message control (bcm) module that handles CAN bus message broadcasting operations. The issue stems from improper handling of RCU (Read-Copy-Update) list annotations and operations during the initialization and cleanup of bcm operation structures. The vulnerability manifests when bcm_proc_show() function attempts to traverse bcm_op structures under an rcu_read_lock() context, but these structures are not properly initialized with the required rcu list operations during their creation phase.
The technical flaw occurs because the bcm_rx_setup() and bcm_tx_setup() functions fail to use list_add_rcu() for adding newly created bcm_op structures to their respective operation lists. This omission means that when bcm_proc_show() later traverses these lists while holding an RCU read lock, it encounters improperly initialized structures that may have been partially constructed or lack proper RCU synchronization mechanisms. The root cause lies in the improper sequencing of list operations during structure initialization, where list_add_rcu() calls were positioned incorrectly within the setup code sequence.
The operational impact of this vulnerability extends to potential system instability and memory corruption scenarios when the bcm_proc_show() function processes the operation lists under RCU protection. Attackers could potentially exploit this by manipulating CAN bus operations in ways that trigger the improper list handling during concurrent access patterns, leading to use-after-free conditions or memory corruption. The vulnerability also affects the cleanup path through bcm_release() which calls bcm_remove_op() on operations still linked in the tx_ops or rx_ops lists without first removing them with list_del_rcu(). This pattern mismatch creates a race condition where freed memory structures may still be referenced during RCU read-side critical sections.
The fix implemented addresses both initialization and cleanup phases by moving list_add_rcu() calls to the end of setup code execution, ensuring all bcm_op structure fields are properly initialized before they become visible to RCU readers. Additionally, the cleanup mechanism in bcm_release() now properly unlinks operations using list_del_rcu() before passing them to bcm_remove_op(), which uses call_rcu() for asynchronous freeing. This pattern aligns with existing code conventions found in bcm_delete_tx_op() and bcm_delete_rx_op() functions, maintaining consistency across the module's operation handling.
This vulnerability maps to CWE-119 Improper Access of Resources via Pointer, specifically addressing memory safety issues related to improper list management within kernel space concurrent access patterns. The remediation follows ATT&CK technique T1068 Exploitation for Privilege Escalation by ensuring proper kernel memory management that prevents potential privilege escalation through memory corruption vulnerabilities. The fix demonstrates the critical importance of maintaining RCU synchronization semantics in kernel data structures, particularly when dealing with shared lists accessed under read-side critical sections. The vulnerability highlights the complexity of kernel-level concurrent programming where improper ordering of list operations can lead to subtle but serious stability issues in real-time systems that depend on CAN bus communication protocols.
The security implications extend beyond simple memory corruption as this vulnerability could potentially allow local privilege escalation or denial of service conditions in embedded systems relying heavily on CAN bus communications. Systems utilizing automotive, industrial control, or network infrastructure components that depend on the Linux kernel's CAN subsystem may be affected by improper handling of broadcast message operations during concurrent access scenarios. The fix ensures proper synchronization between initialization and cleanup phases while maintaining the expected behavior of the bcm module under normal operational conditions, preserving system stability while eliminating the race condition that could lead to arbitrary code execution or system crashes.