Race Condition Affecting kernel-source-azure package, versions <6.4.0-150700.20.27.1
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-SLES157-KERNELSOURCEAZURE-15276645
- published13 Feb 2026
- disclosed12 Feb 2026
Introduced: 12 Feb 2026
CVE-2024-27005 (opens in a new tab)How to fix?
Upgrade SLES:15.7 kernel-source-azure to version 6.4.0-150700.20.27.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-source-azure package and not the kernel-source-azure package as distributed by SLES.
See How to fix? for SLES:15.7 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
interconnect: Don't access req_list while it's being manipulated
The icc_lock mutex was split into separate icc_lock and icc_bw_lock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to icc_node::req_list.
The icc_set_bw() function will eventually iterate over req_list while only holding icc_bw_lock, but req_list can be modified while only holding icc_lock. This causes races between icc_set_bw(), of_icc_get(), and icc_put().
Example A:
CPU0 CPU1
icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(... <r = invalid pointer>
Example B:
CPU0 CPU1
icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(... <r = invalid pointer>
Fix this by ensuring icc_bw_lock is always held before manipulating icc_node::req_list. The additional places icc_bw_lock is held don't perform any memory allocations, so we should still be safe from the original lockdep splats that motivated the separate locks.
[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
References
- https://www.suse.com/security/cve/CVE-2024-27005.html
- https://bugzilla.suse.com/1223800
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
- https://git.kernel.org/stable/c/19ec82b3cad1abef2a929262b8c1528f4e0c192d
- https://git.kernel.org/stable/c/fe549d8e976300d0dd75bd904eb216bed8b145e0
- https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6
- https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42
- https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1