CVE-2026-72116
CVE CVE-2026-72116EUVD EUVD-2026-59074Veröffentlicht 2026-08-15T05:52:56.000ZZuletzt geändert 2026-08-19T16:36:05.000ZCVSS 7.1
Was das Advisory beschreibt
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.
Quelle: EUVD (ENISA), im Wortlaut der Meldung.
Produkte, die das Advisory nennt
Diese Angaben stammen aus der Meldung selbst, nicht aus einer Prüfung durch uns.
- 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
Die genannten Versionen sind die Angabe der Meldung. Patchlage vergleicht keine Versionsnummern und leitet aus ihnen keine Aussage ab — welche Version installiert ist, muss ein Mensch nachsehen.
Im Produktkatalog geführt
Für diese Produkte kann ein Bestand in Patchlage erfasst werden. Ein Advisory dazu erscheint am Morgen danach im Lagebericht.
- Linux — Linux
Betrifft das einen Ihrer Kundenbestände?
Diese Seite kann die Frage nicht beantworten — sie kennt Ihren Bestand nicht. Wer seine Umgebungen erfasst hat, bekommt die Antwort am Morgen nach der Veröffentlichung, zusammen mit einem Absatz, den er unverändert an den Kunden weitergeben kann.
28 Tage testenPatchlage meldet Treffer und Verdachtsfälle. Zu allem anderen sagt dieses System nichts — weder diese Seite noch der Lagebericht behauptet je, dass ein Bestand sicher ist.