CVE-2026-72116: can: bcm: fix stale rx/tx ops after device removal

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

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

RX: an RXSETUP update(!) for an existing op skipped canrxregister() unconditionally, even when a concurrent NETDEVUNREGISTER had already torn down its registration (op->rxregdev == NULL). This silently did not re-enable frame delivery for that updated filter. bcmrxsetup() now re-registers in that case, while leaving rxops with ifindex = 0 (all CAN devices) which never carry a tracked rxregdev registered as-is.

TX: bcmnotify() only handled bo->rxops on NETDEVUNREGISTER, leaving txops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcmtxtimeouthandler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcmcantx() for the op until an explicit TXSETUP update re-arms it.

Unlike bcmrxunreg(), which clears the tracked rxregdev for rxops, the ifindex is intentionally left unchanged for txops. bcmtxsetup() always rejects ifindex 0, so clearing it would strand the op: neither a later TXSETUP (bcmfindop()) nor TXDELETE (bcmdeletetxop()) could ever find it again, since both require an exact ifindex match.