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().
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72115.json"
}