CVE-2026-72116

In the Linux kernel, the following vulnerability has been resolved:

can: bcm: fix stale rx/tx ops after device removal

RX: an RX_SETUP update(!) for an existing op skipped can_rx_register()

unconditionally, even when a concurrent NETDEV_UNREGISTER had already

torn down its registration (op->rx_reg_dev == NULL). This silently

did not re-enable frame delivery for that updated filter. bcm_rx_setup()

now re-registers in that case, while leaving rx_ops with ifindex = 0

(all CAN devices) which never carry a tracked rx_reg_dev registered as-is.

TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving

tx_ops with an active cyclic transmission re-arming its hrtimer

indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer

prevents the runaway timer and any injection into a later reused ifindex,

since nothing else calls bcm_can_tx() for the op until an explicit

TX_SETUP update re-arms it.

Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops,

the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup()

always rejects ifindex 0, so clearing it would strand the op: neither a

later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could

ever find it again, since both require an exact ifindex match.