Answer in brief
CVE-2026-72126 records a Unknown severity vulnerability in can: isotp: use unconditional synchronize_rcu() in isotp_release(). 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.
Answer in brief
CVE-2026-72126 records a Unknown severity vulnerability in can: isotp: use unconditional synchronize_rcu() in isotp_release(). 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 | >=22bfa94db2ef6900c790884fa9461486516626e9 <945d9894502cd9124f5d676181c542ed2000f7c0 || >=14a4696bc3118ba49da28f79280e1d55603aa737 <59672aa4bcd8d32172c1ff6a179583981d6acabc || >=14a4696bc3118ba49da28f79280e1d55603aa737 <15413a082df69175c2f96aeab4c26fe1ff7cff03 || >=14a4696bc3118ba49da28f79280e1d55603aa737 <6280eda96e0707264849fa7d036fed873c1f8a6d || >=14a4696bc3118ba49da28f79280e1d55603aa737 <cb6abc584a1bfab107ac003d64948a4aef1730aa || >=14a4696bc3118ba49da28f79280e1d55603aa737 <b88a511308779c225005d7994b8744561bdbafbc || >=14a4696bc3118ba49da28f79280e1d55603aa737 <b8278ff605187ef3fa0f2705e93251cce4c4f8ee || >=14a4696bc3118ba49da28f79280e1d55603aa737 <9b1a02e0d980ac6b0e36a90378f847062f81d7e4 || 80c6ddf771df2ef786f28c1ca5919b3f1080091b || ebf91625b3e404bd2b4b694c7ee71c1e8f8bd08f || >=5.10.50 <5.10.261 || >=5.12.17 <5.13 || >=5.13.2 <5.14 | 945d9894502cd9124f5d676181c542ed2000f7c0, 59672aa4bcd8d32172c1ff6a179583981d6acabc, 15413a082df69175c2f96aeab4c26fe1ff7cff03, 6280eda96e0707264849fa7d036fed873c1f8a6d, cb6abc584a1bfab107ac003d64948a4aef1730aa, b88a511308779c225005d7994b8744561bdbafbc, b8278ff605187ef3fa0f2705e93251cce4c4f8ee, 9b1a02e0d980ac6b0e36a90378f847062f81d7e4, 5.10.261, 5.13, 5.14 |
| Linux/Linuxgeneric | 5.14 | 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: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path.
Quoted source text, attributed separately from HOL analysis.
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 | >=22bfa94db2ef6900c790884fa9461486516626e9 <945d9894502cd9124f5d676181c542ed2000f7c0 || >=14a4696bc3118ba49da28f79280e1d55603aa737 <59672aa4bcd8d32172c1ff6a179583981d6acabc || >=14a4696bc3118ba49da28f79280e1d55603aa737 <15413a082df69175c2f96aeab4c26fe1ff7cff03 || >=14a4696bc3118ba49da28f79280e1d55603aa737 <6280eda96e0707264849fa7d036fed873c1f8a6d || >=14a4696bc3118ba49da28f79280e1d55603aa737 <cb6abc584a1bfab107ac003d64948a4aef1730aa || >=14a4696bc3118ba49da28f79280e1d55603aa737 <b88a511308779c225005d7994b8744561bdbafbc || >=14a4696bc3118ba49da28f79280e1d55603aa737 <b8278ff605187ef3fa0f2705e93251cce4c4f8ee || >=14a4696bc3118ba49da28f79280e1d55603aa737 <9b1a02e0d980ac6b0e36a90378f847062f81d7e4 || 80c6ddf771df2ef786f28c1ca5919b3f1080091b || ebf91625b3e404bd2b4b694c7ee71c1e8f8bd08f || >=5.10.50 <5.10.261 || >=5.12.17 <5.13 || >=5.13.2 <5.14 | 945d9894502cd9124f5d676181c542ed2000f7c0, 59672aa4bcd8d32172c1ff6a179583981d6acabc, 15413a082df69175c2f96aeab4c26fe1ff7cff03, 6280eda96e0707264849fa7d036fed873c1f8a6d, cb6abc584a1bfab107ac003d64948a4aef1730aa, b88a511308779c225005d7994b8744561bdbafbc, b8278ff605187ef3fa0f2705e93251cce4c4f8ee, 9b1a02e0d980ac6b0e36a90378f847062f81d7e4, 5.10.261, 5.13, 5.14 |
| Linux/Linuxgeneric | 5.14 | 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: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path.
Quoted source text, attributed separately from HOL analysis.