This CVE exposes a design tension in the CAN BCM driver where the fix for the TX path couldn't simply clear the ifindex on device removal — doing so would strand the operation entirely because both TX_SETUP and TX_DELETE look up operations by exact ifindex match. The kernel had to cancel the hrtimer to prevent it from firing against a reused ifindex, but the stale ifindex remains findable in the tx_ops list. This wasn't a security constraint; it was a downstream consequence of using ifindex as both an identity handle and a lookup key without validating that the referent still exists.
The RX path avoids this trap through rx_reg_dev tracking, which enables explicit NULL checks before re-registration — a more robust pattern that accommodates device lifecycle transitions cleanly. TX operations couldn't adopt this model because they carry operational state: when a user sets up a TX filter for can0, they're expressing intent toward a specific interface handle. Clearing that handle on unregistration would lose the user's semantic binding, and there's no separate device abstraction to recover it.
The silent failure mode in the RX path compounds this. An RX_SETUP update can return success while actually disabling frame delivery if the device has already unregistered — can_rx_register() returns zero, the filter appears updated, but frames are silently dropped. This error mode persists through code review because nothing fails visibly and the update path has no visibility into stale registration state.
The blast radius of this fix is temporal: each NETDEV_UNREGISTER event leaves a zombie tx_op that's findable but invalid. Until TX_DELETE or the next TX_SETUP explicitly resolves those entries, they're live blast radius for future code paths that traverse tx_ops. The fix prevents one specific failure mode (timer injection into a reused ifindex) while preserving the underlying condition that creates risk for future bugs.