CyberSecBulletin
CVE-2024-27005NVD status: Modified

Linux: Concurrent Execution using Shared Resource with Improper Synchronization

CVE-2024-27005 is a high-severity concurrent execution using shared resource with improper synchronization vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions fe549d8e976300d0dd75bd904eb216bed8b145e0, 19ec82b3cad1abef2a929262b8c1528f4e0c192d, 8401bc2c188030fb14d1cb43c402a1cf42d86dd2 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.19% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Linux to fe549d8e976300d0dd75bd904eb216bed8b145e0 or 19ec82b3cad1abef2a929262b8c1528f4e0c192d or 8401bc2c188030fb14d1cb43c402a1cf42d86dd2 or d0d04efa2e367921654b5106cc5c05e3757c2b42, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 5.16 or 6.2 or 6.6.29 or 6.8.8, whichever matches your release line, or a later version.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux9be2957f014d91088db1eb5dd09d9a03d7184dce up to, but not including, fe549d8e976300d0dd75bd904eb216bed8b145e0; ee42bfc791aa3cd78e29046f26a09d189beb3efb up to, but not including, 19ec82b3cad1abef2a929262b8c1528f4e0c192d; ffb8917c70a4c88725ee40f9eeee9240ad1c1869 up to, but not including, 8401bc2c188030fb14d1cb43c402a1cf42d86dd2; af42269c3523492d71ebbe11fefae2653e9cdc78 up to, but not including, d0d04efa2e367921654b5106cc5c05e3757c2b42; af42269c3523492d71ebbe11fefae2653e9cdc78 up to, but not including, 4c65507121ea8e0b47fae6d2049c8688390d46b6; af42269c3523492d71ebbe11fefae2653e9cdc78 up to, but not including, de1bf25b6d771abdb52d43546cf57ad775fb68a1; 2f3a124696d43de3c837f87a9f767c56ee86cf2a; 5.15.133 up to, but not including, 5.15.151; and 3 more rangesfe549d8e976300d0dd75bd904eb216bed8b145e0, 19ec82b3cad1abef2a929262b8c1528f4e0c192d, 8401bc2c188030fb14d1cb43c402a1cf42d86dd2, d0d04efa2e367921654b5106cc5c05e3757c2b42, 4c65507121ea8e0b47fae6d2049c8688390d46b6, de1bf25b6d771abdb52d43546cf57ad775fb68a1
LinuxLinux Kernel5.15.133 up to, but not including, 5.16; 6.1.55 up to, but not including, 6.2; 6.5.5 up to, but not including, 6.6.29; 6.7 up to, but not including, 6.8.8; 6.95.16, 6.2, 6.6.29, 6.8.8

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
LocalThe attacker needs local access or must trick a user into running something.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
LowA basic user account is enough.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

Scoring systemScoreSeverityScored by
CVSS 3.17.8HighCNA
CVSS 3.16.3MediumCISA (ADP)

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

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Concurrent Execution using Shared Resource with Improper Synchronization

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

How developers prevent this class of flaw

  • In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
  • Use thread-safe capabilities such as the data access abstraction in Spring.
  • Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

More Concurrent Execution using Shared Resource with Improper Synchronization vulnerabilities (CWE-362)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: partial).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Concurrent Execution using Shared Resource with Improper Synchronization vulnerabilities

Spotted an error? Tell us.