Race Condition Affecting kernel-debug-devel-matched package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL10-KERNELDEBUGDEVELMATCHED-18898727
- published18 Aug 2026
- disclosed15 Aug 2026
Introduced: 15 Aug 2026
NewCVE-2026-72115 (opens in a new tab)How to fix?
There is no fixed version for RHEL:10 kernel-debug-devel-matched.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-debug-devel-matched package and not the kernel-debug-devel-matched package as distributed by RHEL.
See How to fix? for RHEL:10 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: track a single source interface for ANYDEV timeout/throttle ops
An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op.
Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration.
The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values.
A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2516402
- https://access.redhat.com/security/cve/CVE-2026-72115
- https://git.kernel.org/stable/c/18b45251e74e35668f0dd0c470549384ae191ecf
- https://git.kernel.org/stable/c/2f5976f54a04e9f18b25283036ac3136be453b17
- https://git.kernel.org/stable/c/3ff8c24b421070a2db99a5cdb86edc9ff339418e
- https://git.kernel.org/stable/c/b6317022b685a430a3ae420456716e3c0c02ef4b
- https://git.kernel.org/stable/c/eca8b44d51fc6ab61022258ec968e55e3073b79e