GHSA-85WX-H4W2-C465
Vulnerability from github – Published: 2026-08-15 06:32 – Updated: 2026-08-19 18:32In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add locking when updating filter and timer values
KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic.
Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock.
hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller.
Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent.
bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call.
Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx().
Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.
{
"affected": [],
"aliases": [
"CVE-2026-72121"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-15T06:21:26Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add locking when updating filter and timer values\n\nKCSAN detected a simultaneous access to timer values that can be\noverwritten in bcm_rx_setup() when updating timer and filter content\nwhile bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler()\nrun concurrently on incoming CAN traffic.\n\nProtect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter\n(nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new\nper-op bcm_rx_update_lock, taken with the matching scope in the RX\nhandlers. memcpy_from_msg() is staged into a temporary buffer before the\nlock is taken, since it can sleep and must not run under a spinlock.\n\nhrtimer_cancel() is always called without bcm_rx_update_lock held, since\nbcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a\nrunning callback would otherwise deadlock against the canceller.\n\nAlso close a related race: bcm_rx_setup() cleared the RTR flag in the\nstored reply frame\u0027s can_id as a separate, unprotected step after the\nframe content was already installed, so a concurrent bcm_rx_handler()\ncould transmit a stale reply with CAN_RTR_FLAG still set. Fold that\nnormalization into the initial frame preparation instead (on the staged\nbuffer for updates, directly on op-\u003eframes pre-registration for new\nops), so the installed frame is always atomically self-consistent.\n\nbcm_rx_handler()\u0027s RX_RTR_FRAME check now takes a lock-protected\nsnapshot of op-\u003eflags before deciding whether to call bcm_can_tx(),\nbut does not hold the lock across that call.\n\nAlso take a lock-protected snapshot of the currframe in bcm_can_tx()\nto avoid partly overwrites by content updates in bcm_tx_setup().\nFinally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset\nop-\u003ecurrframe between the two locked sections in bcm_can_tx().\n\nOmit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler().\nkt_ival2 may have been concurrently cleared by bcm_rx_setup() before it\ncancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.",
"id": "GHSA-85wx-h4w2-c465",
"modified": "2026-08-19T18:32:27Z",
"published": "2026-08-15T06:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72121"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19b1994069dd29478ba767de1f98f14a088198dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/749179c2e25b95d22499ed29096b3e02d6dfd2b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/834cbca3b12e46887f7a9b35f1981a888360ea4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96994180bd7b248b0cc698afe926e23fc1bda59b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7c369e7da8203e2b5be12bbcac7b9ab2ed5b658"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7eb6db1cd3f7b556a301dc1265945ad112089f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/caa8704a7f3cb7806331596195385437126ecb3a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc9f5ee1b073bd233d9c604e338af4ebb42cbc33"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.