CVE-2024-49976: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for "trace/osnoise:online", since commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the "kthread" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.
AI Analysis
Technical Summary
CVE-2024-49976 is a concurrency-related vulnerability in the Linux kernel's tracing subsystem, specifically within the timerlat component used for measuring timer latency and OS noise. The issue arises from a deadlock scenario introduced by a recent code change (commit 5bfbcd1ee57b) that added an interface_lock mutex around the clearing of a kernel thread (kthread) in the stop_kthread() function. This function acts as an offline callback for the tracepoint "trace/osnoise:online". The deadlock occurs due to an ABBA lock order inversion involving three threads: osnoise_hotplug_workfn(), work_for_cpu_fn(), and cpuhp_thread_fun(). The locks involved are interface_lock, cpus_read_lock(), and cpus_write_lock(), which are acquired in conflicting orders across these threads, causing a potential system hang or kernel freeze. The root cause is that interface_lock was used to protect the kthread field of the osn_var structure, but this introduced the deadlock. The fix replaces the mutex protection with an atomic exchange operation (xchg()) to update the kthread pointer without requiring the interface_lock, thereby eliminating the deadlock risk. Additionally, the fix reverts to using for_each_online_cpu() in stop_per_cpu_kthreads() to avoid reacquiring cpu_read_lock(), further preventing lock order conflicts. This vulnerability affects specific Linux kernel commits identified by their hashes, indicating it is present in certain recent kernel versions. No known exploits are reported in the wild at this time, and no CVSS score has been assigned yet. The vulnerability is primarily a denial-of-service risk due to potential kernel deadlock and system unresponsiveness caused by the locking issue.
Potential Impact
For European organizations, the primary impact of CVE-2024-49976 is the risk of denial-of-service (DoS) conditions on Linux systems running affected kernel versions. Since Linux is widely used in servers, cloud infrastructure, embedded devices, and critical industrial systems across Europe, a kernel deadlock can cause system hangs, service outages, and potential disruption of business-critical applications. This is particularly concerning for sectors relying on high availability such as finance, telecommunications, healthcare, and public infrastructure. Although no remote code execution or privilege escalation is indicated, the inability to recover from kernel deadlocks without a reboot can lead to operational downtime and increased maintenance costs. Systems running real-time monitoring or tracing tools that utilize the timerlat or osnoise tracing features are more directly impacted. The vulnerability does not appear to require user interaction or authentication, meaning local processes or kernel threads can trigger the deadlock. This increases the risk in multi-tenant environments or shared hosting where untrusted users might induce the condition. Overall, the threat to confidentiality and integrity is low, but availability impact is medium to high depending on deployment context.
Mitigation Recommendations
To mitigate CVE-2024-49976, European organizations should: 1) Apply the official Linux kernel patches that replace interface_lock usage with atomic operations in stop_kthread() and revert to safer CPU iteration methods in stop_per_cpu_kthreads(). Monitoring Linux kernel mailing lists and vendor advisories for backported fixes is critical. 2) Identify and inventory all Linux systems running affected kernel versions (those including the specified commit hashes) and prioritize patching on critical infrastructure. 3) For environments where immediate patching is not feasible, consider disabling or limiting the use of the tracing timerlat/osnoise features if possible, to reduce exposure. 4) Implement robust monitoring to detect kernel hangs or deadlocks, including system responsiveness checks and kernel logs analysis for lock contention warnings. 5) Employ kernel live patching solutions where supported to minimize downtime during patch deployment. 6) Review and restrict local user permissions to prevent untrusted users from triggering tracing operations that could lead to deadlocks. 7) Engage with Linux distribution vendors for timely security updates and guidance tailored to specific distributions used in European environments.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy, Spain, Poland, Belgium
CVE-2024-49976: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for "trace/osnoise:online", since commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the "kthread" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.
AI-Powered Analysis
Technical Analysis
CVE-2024-49976 is a concurrency-related vulnerability in the Linux kernel's tracing subsystem, specifically within the timerlat component used for measuring timer latency and OS noise. The issue arises from a deadlock scenario introduced by a recent code change (commit 5bfbcd1ee57b) that added an interface_lock mutex around the clearing of a kernel thread (kthread) in the stop_kthread() function. This function acts as an offline callback for the tracepoint "trace/osnoise:online". The deadlock occurs due to an ABBA lock order inversion involving three threads: osnoise_hotplug_workfn(), work_for_cpu_fn(), and cpuhp_thread_fun(). The locks involved are interface_lock, cpus_read_lock(), and cpus_write_lock(), which are acquired in conflicting orders across these threads, causing a potential system hang or kernel freeze. The root cause is that interface_lock was used to protect the kthread field of the osn_var structure, but this introduced the deadlock. The fix replaces the mutex protection with an atomic exchange operation (xchg()) to update the kthread pointer without requiring the interface_lock, thereby eliminating the deadlock risk. Additionally, the fix reverts to using for_each_online_cpu() in stop_per_cpu_kthreads() to avoid reacquiring cpu_read_lock(), further preventing lock order conflicts. This vulnerability affects specific Linux kernel commits identified by their hashes, indicating it is present in certain recent kernel versions. No known exploits are reported in the wild at this time, and no CVSS score has been assigned yet. The vulnerability is primarily a denial-of-service risk due to potential kernel deadlock and system unresponsiveness caused by the locking issue.
Potential Impact
For European organizations, the primary impact of CVE-2024-49976 is the risk of denial-of-service (DoS) conditions on Linux systems running affected kernel versions. Since Linux is widely used in servers, cloud infrastructure, embedded devices, and critical industrial systems across Europe, a kernel deadlock can cause system hangs, service outages, and potential disruption of business-critical applications. This is particularly concerning for sectors relying on high availability such as finance, telecommunications, healthcare, and public infrastructure. Although no remote code execution or privilege escalation is indicated, the inability to recover from kernel deadlocks without a reboot can lead to operational downtime and increased maintenance costs. Systems running real-time monitoring or tracing tools that utilize the timerlat or osnoise tracing features are more directly impacted. The vulnerability does not appear to require user interaction or authentication, meaning local processes or kernel threads can trigger the deadlock. This increases the risk in multi-tenant environments or shared hosting where untrusted users might induce the condition. Overall, the threat to confidentiality and integrity is low, but availability impact is medium to high depending on deployment context.
Mitigation Recommendations
To mitigate CVE-2024-49976, European organizations should: 1) Apply the official Linux kernel patches that replace interface_lock usage with atomic operations in stop_kthread() and revert to safer CPU iteration methods in stop_per_cpu_kthreads(). Monitoring Linux kernel mailing lists and vendor advisories for backported fixes is critical. 2) Identify and inventory all Linux systems running affected kernel versions (those including the specified commit hashes) and prioritize patching on critical infrastructure. 3) For environments where immediate patching is not feasible, consider disabling or limiting the use of the tracing timerlat/osnoise features if possible, to reduce exposure. 4) Implement robust monitoring to detect kernel hangs or deadlocks, including system responsiveness checks and kernel logs analysis for lock contention warnings. 5) Employ kernel live patching solutions where supported to minimize downtime during patch deployment. 6) Review and restrict local user permissions to prevent untrusted users from triggering tracing operations that could lead to deadlocks. 7) Engage with Linux distribution vendors for timely security updates and guidance tailored to specific distributions used in European environments.
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
- 2024-10-21T12:17:06.052Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9824c4522896dcbdfbc9
Added to database: 5/21/2025, 9:08:52 AM
Last enriched: 6/28/2025, 3:42:31 PM
Last updated: 7/31/2025, 9:46:30 AM
Views: 12
Related Threats
CVE-2025-52621: CWE-346 Origin Validation Error in HCL Software BigFix SaaS Remediate
MediumCVE-2025-52620: CWE-20 Improper Input Validation in HCL Software BigFix SaaS Remediate
MediumCVE-2025-52619: CWE-209 Generation of Error Message Containing Sensitive Information in HCL Software BigFix SaaS Remediate
MediumCVE-2025-52618: CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') in HCL Software BigFix SaaS Remediate
MediumCVE-2025-43201: An app may be able to unexpectedly leak a user's credentials in Apple Apple Music Classical for Android
HighActions
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.