CVE-2024-47143: Vulnerability in Linux Linux
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().
AI Analysis
Technical Summary
CVE-2024-47143 is a concurrency-related vulnerability in the Linux kernel's dma-debug subsystem, specifically involving a potential deadlock scenario caused by improper lock ordering between radix_lock() and dma_hash_entry[idx].lock. The vulnerability arises when radix_lock() is held simultaneously with dma_hash_entry lock, which can lead to a deadlock during certain kernel operations involving DMA debug API calls while holding rq_lock(). The deadlock scenario is illustrated across multiple CPUs where different kernel threads attempt to acquire locks in conflicting orders, causing a circular wait condition. This can occur in contexts such as memory management (kswapd wake-up), hardware tracing (perf_event_task_sched_out with Arm Coresight backends), and DMA synchronization operations. The root cause is that dma_entry_free() is called while still holding the hash bucket lock, which conflicts with radix_lock() acquisition in other threads. The fix involves reordering the calls to ensure dma_entry_free() is invoked only after releasing the hash bucket lock in check_unmap(), thereby preventing the deadlock condition. This vulnerability affects specific Linux kernel versions identified by the commit hash 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2. There are no known exploits in the wild at the time of publication, and no CVSS score has been assigned yet.
Potential Impact
For European organizations relying on Linux-based systems, especially those using kernels with the affected versions, this vulnerability could lead to system hangs or freezes due to kernel deadlocks. Such deadlocks can degrade system availability, impacting critical infrastructure, servers, and embedded devices running Linux. The deadlock occurs in kernel subsystems related to DMA debugging and hardware tracing, which are often used in performance monitoring and debugging in enterprise environments. While this vulnerability does not directly expose confidentiality or integrity risks, the availability impact could disrupt services, delay operations, and increase downtime. Organizations with high-reliability requirements, such as telecommunications, finance, manufacturing, and cloud service providers, could face operational challenges if affected systems encounter this deadlock. The lack of known exploits reduces immediate risk, but the complexity of the issue means that kernel developers and system administrators must prioritize patching to avoid potential future exploitation or accidental system failures.
Mitigation Recommendations
European organizations should promptly update their Linux kernels to versions that include the patch fixing CVE-2024-47143. Since the vulnerability is related to kernel internal locking mechanisms, applying the official kernel patches or upgrading to a fixed kernel release is the most effective mitigation. For environments where immediate patching is not feasible, administrators should monitor system logs for signs of deadlock or kernel hangs related to dma-debug or hardware tracing subsystems. Disabling or limiting the use of dma-debug and hardware tracing features temporarily may reduce exposure, though this could impact debugging capabilities. Organizations should also review and test kernel updates in staging environments to ensure compatibility and stability before deployment. Maintaining robust backup and recovery procedures will help mitigate downtime if deadlocks occur. Additionally, system architects should consider isolating critical workloads from debug-heavy kernel features to minimize risk.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy, Spain
CVE-2024-47143: Vulnerability in Linux Linux
Description
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().
AI-Powered Analysis
Technical Analysis
CVE-2024-47143 is a concurrency-related vulnerability in the Linux kernel's dma-debug subsystem, specifically involving a potential deadlock scenario caused by improper lock ordering between radix_lock() and dma_hash_entry[idx].lock. The vulnerability arises when radix_lock() is held simultaneously with dma_hash_entry lock, which can lead to a deadlock during certain kernel operations involving DMA debug API calls while holding rq_lock(). The deadlock scenario is illustrated across multiple CPUs where different kernel threads attempt to acquire locks in conflicting orders, causing a circular wait condition. This can occur in contexts such as memory management (kswapd wake-up), hardware tracing (perf_event_task_sched_out with Arm Coresight backends), and DMA synchronization operations. The root cause is that dma_entry_free() is called while still holding the hash bucket lock, which conflicts with radix_lock() acquisition in other threads. The fix involves reordering the calls to ensure dma_entry_free() is invoked only after releasing the hash bucket lock in check_unmap(), thereby preventing the deadlock condition. This vulnerability affects specific Linux kernel versions identified by the commit hash 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2. There are no known exploits in the wild at the time of publication, and no CVSS score has been assigned yet.
Potential Impact
For European organizations relying on Linux-based systems, especially those using kernels with the affected versions, this vulnerability could lead to system hangs or freezes due to kernel deadlocks. Such deadlocks can degrade system availability, impacting critical infrastructure, servers, and embedded devices running Linux. The deadlock occurs in kernel subsystems related to DMA debugging and hardware tracing, which are often used in performance monitoring and debugging in enterprise environments. While this vulnerability does not directly expose confidentiality or integrity risks, the availability impact could disrupt services, delay operations, and increase downtime. Organizations with high-reliability requirements, such as telecommunications, finance, manufacturing, and cloud service providers, could face operational challenges if affected systems encounter this deadlock. The lack of known exploits reduces immediate risk, but the complexity of the issue means that kernel developers and system administrators must prioritize patching to avoid potential future exploitation or accidental system failures.
Mitigation Recommendations
European organizations should promptly update their Linux kernels to versions that include the patch fixing CVE-2024-47143. Since the vulnerability is related to kernel internal locking mechanisms, applying the official kernel patches or upgrading to a fixed kernel release is the most effective mitigation. For environments where immediate patching is not feasible, administrators should monitor system logs for signs of deadlock or kernel hangs related to dma-debug or hardware tracing subsystems. Disabling or limiting the use of dma-debug and hardware tracing features temporarily may reduce exposure, though this could impact debugging capabilities. Organizations should also review and test kernel updates in staging environments to ensure compatibility and stability before deployment. Maintaining robust backup and recovery procedures will help mitigate downtime if deadlocks occur. Additionally, system architects should consider isolating critical workloads from debug-heavy kernel features to minimize risk.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2025-01-09T09:49:29.749Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9825c4522896dcbe03f0
Added to database: 5/21/2025, 9:08:53 AM
Last enriched: 6/28/2025, 7:10:37 PM
Last updated: 7/29/2025, 1:10:45 AM
Views: 22
Related Threats
CVE-2025-9026: OS Command Injection in D-Link DIR-860L
MediumCVE-2025-9025: SQL Injection in code-projects Simple Cafe Ordering System
MediumCVE-2025-9024: SQL Injection in PHPGurukul Beauty Parlour Management System
MediumCVE-2025-9023: Buffer Overflow in Tenda AC7
HighCVE-2025-8905: CWE-94 Improper Control of Generation of Code ('Code Injection') in inpersttion Inpersttion For Theme
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.