CVE-2024-47143

dma-debug: fix a possible deadlock on radix_lock

Medium · published January 11, 2025

CVSS v3.1
5.5
EPSS
0%
Percentile
8.0
In the wild
Unconfirmed
What it is

In the Linux kernel, the following vulnerability has been resolved:

dma-debug: fix a possible deadlock on radix_lock

radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock

otherwise, there's a possible deadlock scenario when

dma debug API is called holding rq_lock():

CPU0 CPU1 CPU2

dma_free_attrs()

check_unmap() add_dma_entry() __schedule() //out

(A) rq_lock()

get_hash_bucket()

(A) dma_entry_hash

check_sync()

(A) radix_lock() (W) dma_entry_hash

dma_entry_free()

(W) radix_lock()

// CPU2's one

(W) rq_lock()

CPU1 situation can happen when it extending radix tree and

it tries to wake up kswapd via wake_all_kswapd().

CPU2 situation can happen while perf_event_task_sched_out()

(i.e. dma sync operation is called while deleting perf_event using

etm and etr tmc which are Arm Coresight hwtracing driver backends).

To remove this possible situation, call dma_entry_free() after

put_hash_bucket() in check_unmap().

The record
Technical detail
CVSS v3.1
5.5 · MEDIUM
Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0
Not supplied
EPSS
0.00188 · 8.0th percentile
Published
2025-01-11T12:25Z
EPSS history
Timeline
  • 11 JAN 12:25Z
    dma-debug: fix a possible deadlock on radix_lock
    cvelistv5