Answer in brief
CVE-2026-72117 records a Unknown severity vulnerability in can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <5f246b96ab47523ec9b8ea870b5c567a3cb1eb1c || >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <656ff69ef235699035e57d9e1ae417e62a38aa7f || >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <136de17f38630307991c59aa7080012a99451783 || >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <c312b750bb5ac3348cfc85dab25e90937bd4d251 || >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8 | 5f246b96ab47523ec9b8ea870b5c567a3cb1eb1c, 656ff69ef235699035e57d9e1ae417e62a38aa7f, 136de17f38630307991c59aa7080012a99451783, c312b750bb5ac3348cfc85dab25e90937bd4d251, 58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8 |
| Linux/Linuxgeneric | 2.6.25 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-72117 records a Unknown severity vulnerability in can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <5f246b96ab47523ec9b8ea870b5c567a3cb1eb1c || >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <656ff69ef235699035e57d9e1ae417e62a38aa7f || >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <136de17f38630307991c59aa7080012a99451783 || >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <c312b750bb5ac3348cfc85dab25e90937bd4d251 || >=ffd980f976e7fd666c2e61bf8ab35107efd11828 <58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8 | 5f246b96ab47523ec9b8ea870b5c567a3cb1eb1c, 656ff69ef235699035e57d9e1ae417e62a38aa7f, 136de17f38630307991c59aa7080012a99451783, c312b750bb5ac3348cfc85dab25e90937bd4d251, 58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8 |
| Linux/Linuxgeneric | 2.6.25 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.