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

  CPU                               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

  CPU                               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.

Exploit Details

The vulnerability arises from improper synchronization between icc_set_bw(), of_icc_get(), and icc_put() functions. An attacker could trigger this vulnerability by exploiting the race conditions between these functions, as shown in Example A and Example B. Successful exploitation could lead to a use-after-free or a double-free scenario, which may further elevate the attacker's privileges, cause denial of service, or execute arbitrary code.

[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")

https://lore.kernel.org/lkml/af42269c3523.163636081.git.sboyd@kernel.org/

Solution

Upgrade to the Linux kernel version that contains the patch for this issue, which ensures that icc_bw_lock is always held before manipulating icc_node::req_list. This resolves the vulnerability and provides better protection against these race conditions.

In summary, CVE-2024-27005 is a vulnerability in the Linux kernel's interconnect subsystem that allows for potential race conditions. By upgrading to a kernel version with the proper patch applied, users can avoid the negative consequences of this issue and enjoy a more secure system.

Timeline

Published on: 05/01/2024 06:15:18 UTC
Last modified on: 05/29/2024 05:26:52 UTC