CVE-2024-26725: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2024-26725

In the Linux kernel, the following vulnerability has been resolved: dpll: fix possible deadlock during netlink dump operation Recently, I've been hitting following deadlock warning during dpll pin dump: [52804.637962] ====================================================== [52804.638536] WARNING: possible circular locking dependency detected [52804.639111] 6.8.0-rc2jiri+ #1 Not tainted [52804.639529] ------------------------------------------------------ [52804.640104] python3/2984 is trying to acquire lock: [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780 [52804.641417] but task is already holding lock: [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, at: dpll_lock_dumpit+0x13/0x20 [52804.642747] which lock already depends on the new lock. [52804.643551] the existing dependency chain (in reverse order) is: [52804.644259] -> #1 (dpll_lock){+.+.}-{3:3}: [52804.644836] lock_acquire+0x174/0x3e0 [52804.645271] __mutex_lock+0x119/0x1150 [52804.645723] dpll_lock_dumpit+0x13/0x20 [52804.646169] genl_start+0x266/0x320 [52804.646578] __netlink_dump_start+0x321/0x450 [52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.647575] genl_rcv_msg+0x1ed/0x3b0 [52804.648001] netlink_rcv_skb+0xdc/0x210 [52804.648440] genl_rcv+0x24/0x40 [52804.648831] netlink_unicast+0x2f1/0x490 [52804.649290] netlink_sendmsg+0x36d/0x660 [52804.649742] __sock_sendmsg+0x73/0xc0 [52804.650165] __sys_sendto+0x184/0x210 [52804.650597] __x64_sys_sendto+0x72/0x80 [52804.651045] do_syscall_64+0x6f/0x140 [52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.652001] -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}: [52804.652650] check_prev_add+0x1ae/0x1280 [52804.653107] __lock_acquire+0x1ed3/0x29a0 [52804.653559] lock_acquire+0x174/0x3e0 [52804.653984] __mutex_lock+0x119/0x1150 [52804.654423] netlink_dump+0xb3/0x780 [52804.654845] __netlink_dump_start+0x389/0x450 [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.655842] genl_rcv_msg+0x1ed/0x3b0 [52804.656272] netlink_rcv_skb+0xdc/0x210 [52804.656721] genl_rcv+0x24/0x40 [52804.657119] netlink_unicast+0x2f1/0x490 [52804.657570] netlink_sendmsg+0x36d/0x660 [52804.658022] __sock_sendmsg+0x73/0xc0 [52804.658450] __sys_sendto+0x184/0x210 [52804.658877] __x64_sys_sendto+0x72/0x80 [52804.659322] do_syscall_64+0x6f/0x140 [52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.660281] other info that might help us debug this: [52804.661077] Possible unsafe locking scenario: [52804.661671] CPU0 CPU1 [52804.662129] ---- ---- [52804.662577] lock(dpll_lock); [52804.662924] lock(nlk_cb_mutex-GENERIC); [52804.663538] lock(dpll_lock); [52804.664073] lock(nlk_cb_mutex-GENERIC); [52804.664490] The issue as follows: __netlink_dump_start() calls control->start(cb) with nlk->cb_mutex held. In control->start(cb) the dpll_lock is taken. Then nlk->cb_mutex is released and taken again in netlink_dump(), while dpll_lock still being held. That leads to ABBA deadlock when another CPU races with the same operation. Fix this by moving dpll_lock taking into dumpit() callback which ensures correct lock taking order.

AI Analysis

Technical Summary

CVE-2024-26725 is a concurrency vulnerability in the Linux kernel related to the handling of locking mechanisms during netlink dump operations within the dpll (Digital Phase-Locked Loop) subsystem. The vulnerability arises from a circular locking dependency (deadlock) between two mutexes: nlk_cb_mutex (netlink callback mutex) and dpll_lock. Specifically, the function __netlink_dump_start() holds the nlk_cb_mutex while calling a callback that acquires dpll_lock. Subsequently, nlk_cb_mutex is released and reacquired in netlink_dump() while dpll_lock is still held, creating an ABBA deadlock scenario when concurrent CPUs attempt to acquire these locks in conflicting orders. This deadlock can cause kernel threads to hang, leading to system unresponsiveness or degraded performance. The fix involves deferring the acquisition of dpll_lock to the dumpit() callback, ensuring a consistent lock acquisition order and preventing circular dependencies. The issue affects Linux kernel versions identified by the commit hash 9d71b54b65b1fb6c0d3a6c5c88ba9b915c783fbc and was publicly disclosed on April 3, 2024. There are no known exploits in the wild, and no CVSS score has been assigned yet.

Potential Impact

For European organizations, this vulnerability primarily threatens system stability and availability rather than confidentiality or integrity. Linux is widely used across European enterprises, government agencies, and critical infrastructure, especially in servers, networking equipment, and embedded systems. A deadlock in kernel locking can cause system hangs or crashes, potentially disrupting business operations, critical services, or network communications. Organizations relying on Linux-based infrastructure for telecommunications, cloud services, or industrial control systems could experience outages or degraded performance. Although no direct exploitation for privilege escalation or data breach is indicated, the denial-of-service-like impact could be significant in environments requiring high availability. The absence of known exploits reduces immediate risk, but the vulnerability's presence in kernel code means that any Linux system running affected versions is susceptible to accidental or deliberate triggering of the deadlock under certain workloads or concurrent netlink operations.

Mitigation Recommendations

1. Apply the official Linux kernel patches that address CVE-2024-26725 as soon as they become available to ensure the locking order is corrected. 2. For organizations unable to immediately patch, monitor kernel logs for deadlock warnings related to netlink and dpll_lock to detect potential triggering of this issue. 3. Limit or control workloads that perform intensive netlink dump operations or dpll pin dumps, especially on multi-CPU systems, to reduce the likelihood of deadlock occurrence. 4. Employ kernel live patching solutions where feasible to minimize downtime during patch deployment. 5. Conduct thorough testing of kernel updates in staging environments to verify that the fix does not introduce regressions. 6. Maintain robust system monitoring and alerting to detect early signs of kernel hangs or performance degradation that could indicate deadlock conditions. 7. Collaborate with Linux distribution vendors to receive timely updates and advisories related to this vulnerability.