CVE-2024-27005: linux kernel — Fix

Description

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")

Is your site exposed to CVE-2024-27005?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

6.3

MEDIUM

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H

Weakness Type (CWE)

CWE-362 CWE-362

CWE-667 CWE-667

Affected Products

Vendor	Product	Versions
linux	linux_kernel	5.15.133 — 5.16
linux	linux_kernel	6.1.55 — 6.2
linux	linux_kernel	6.5.5 — 6.6.29
linux	linux_kernel	6.7 — 6.8.8
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All

References

Advisories & Patches

https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6 https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42 https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1 https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6 https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42 https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1

Other References

https://git.kernel.org/stable/c/19ec82b3cad1abef2a929262b8c1528f4e0c192d https://git.kernel.org/stable/c/fe549d8e976300d0dd75bd904eb216bed8b145e0 https://lists.fedoraproject.org/archives/list/[email protected]/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/ https://lists.fedoraproject.org/archives/list/[email protected]/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/ https://lists.fedoraproject.org/archives/list/[email protected]/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/

Frequently Asked Questions

What is CVE-2024-27005? +

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") It has a CVSS v3.1 base score of 6.3 (MEDIUM).

How severe is CVE-2024-27005? +

CVE-2024-27005 has a CVSS v3.1 score of 6.3 out of 10, rated MEDIUM. This is a medium-severity vulnerability that should be remediated as part of regular maintenance.

What products are affected by CVE-2024-27005? +

CVE-2024-27005 affects products from linux, specifically: linux_kernel. Check the affected products table above for specific version ranges.

How do I check if I'm vulnerable to CVE-2024-27005? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-41458

OwnTone Server versions 28.4 through 29.0 contain a race condition vulnerability in the DAAP login handler that allows unauthenticated attackers …

CVE-2025-13036

An authentication bypass security issue exists within FactoryTalk Historian Site Edition. By continually sending requests to the login endpoint, an …

CVE-2025-0372

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in HYPR Passwordless on Windows allows Privilege Escalation.This issue …

CVE-2025-59052

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Angular uses a …

CVE-2024-47534

go-tuf is a Go implementation of The Update Framework (TUF). The go-tuf client inconsistently traces the delegations. For example, if …

CVE-2025-64118

node-tar is a Tar for Node.js. In 7.5.1, using .t (aka .list) with { sync: true } to read tar …

CVE-2024-27005