Skip to main content
VulnerabilityPublished Updated

CVE-2026-72117: Linux kernel · can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()

Affects Linux kernelSource CVE Database V5

0
Compare

Not known to be exploited · fixed in c312b750bb5ac3348cfc85dab25e90937bd4d251 : update Linux kernel when convenient.

Data as of 6 Nov 2026, 17:19 UTC

Severity
Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

Thin evidence

One scorer or none
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-11-06.

Patch
Available – fixed in c312b750bb5ac3348cfc85dab25e90937bd4d251, c8a5d7cb095d3b12bd9dcf752d6ca0ff50872ac5, b64f60c468d149aca22ea56bb842b9730215aaa5 +5

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 15 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 6 Nov 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ ffd980f976e7fd666c2e61bf8ab35107efd11828, < c312b750bb5ac3348cfc85dab25e90937bd4d251
Fixed in
  • c312b750bb5ac3348cfc85dab25e90937bd4d251
LinuxLinuxAffected
  • ≥ ffd980f976e7fd666c2e61bf8ab35107efd11828, < c8a5d7cb095d3b12bd9dcf752d6ca0ff50872ac5
Fixed in
  • c8a5d7cb095d3b12bd9dcf752d6ca0ff50872ac5
LinuxLinuxAffected
  • ≥ ffd980f976e7fd666c2e61bf8ab35107efd11828, < b64f60c468d149aca22ea56bb842b9730215aaa5
Fixed in
  • b64f60c468d149aca22ea56bb842b9730215aaa5
LinuxLinuxAffected
  • ≥ ffd980f976e7fd666c2e61bf8ab35107efd11828, < 656ff69ef235699035e57d9e1ae417e62a38aa7f
Fixed in
  • 656ff69ef235699035e57d9e1ae417e62a38aa7f
LinuxLinuxAffected
  • ≥ ffd980f976e7fd666c2e61bf8ab35107efd11828, < 136de17f38630307991c59aa7080012a99451783
Fixed in
  • 136de17f38630307991c59aa7080012a99451783
LinuxLinuxAffected
  • ≥ ffd980f976e7fd666c2e61bf8ab35107efd11828, < 58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8
Fixed in
  • 58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8

Description

In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.

References

Community reviews

Loading reviews…