CVE-2026-72115: can: bcm: track a single source interface for ANYDEV timeout/throttle ops

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

can: bcm: track a single source interface for ANYDEV timeout/throttle ops

An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcmrxhandler() can run concurrently for the same op on different CPUs, racing hrtimercancel()/ bcmrxstarttimer() against bcmrxtimeouthandler() and causing spurious RXTIMEOUT notifications and lastframes corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rxifindex/rxstamp fields shared by the op.

Add op->ifdetected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcmrxhandler() before hrtimercancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RXRTRFRAME, independent of ktival1/ktival2, since those may briefly hold a stale value from an earlier non-RTR configuration.

The claim is released in bcmnotify() on NETDEVUNREGISTER and in bcmrxsetup() when SETTIMER reconfigures the timer values.

A (re-)claim is only possible on CAN devices in NETREGREGISTERED dev->regstate to cover the release in bcmnotify() where regstate becomes NETREGUNREGISTERING until synchronizenet().