CVE-2026-72116

CVE CVE-2026-72116EUVD EUVD-2026-59074Published 2026-08-15T05:52:56.000ZLast changed 2026-08-19T16:36:05.000ZCVSS 7.1

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 6.12.101; 2.6.25; patch: 5.10.265; ffd980f976e7fd666c2e61bf8ab35107efd11828 <f749e4564952d60e96930c09f2be99955d07c22e; patch: 6.18.42; ffd980f976e7fd666c2e61bf8ab35107efd11828 <9517d8fb0b191398d35b9b7f8c719c1cc7761cb1; ffd980f976e7fd666c2e61bf8ab35107efd11828 <60d8a7942f4ed2d975207aaeba1adb576707e53d; ffd980f976e7fd666c2e61bf8ab35107efd11828 <ca829677ffa2de5d79e06366e19ac1e4f5cc78dd; patch: 6.1.183; patch: 5.15.216; ffd980f976e7fd666c2e61bf8ab35107efd11828 <6be3e1fedf03eab36a2c09d755d1171287b2014b; patch: 7.1.5; patch: 0; ffd980f976e7fd666c2e61bf8ab35107efd11828 <b31d0933509c5a35c0be5736a2ce8df0d1bf112c; patch: 6.6.148; ffd980f976e7fd666c2e61bf8ab35107efd11828 <d30a36066ed3abefb72ae18901f71841ba18b350; ffd980f976e7fd666c2e61bf8ab35107efd11828 <3b762c0d950383ab7a002686c9136b9aa55d2d70; patch: 7.2

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.