CVE-2024-27014 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the `priv->state_lock`, any scheduled aRFS works are canceled using the `cancel_work_sync` function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the `state_lock` which is already acquired.
The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I ------------------------------------------------------ ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}:
__mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core]
process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}:
__lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core]
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
#1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240
#2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core]
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/07/2026
The vulnerability described in CVE-2024-27014 affects the Linux kernel's mlx5e network driver, specifically within the Adaptive RSS (aRFS) functionality. This issue manifests as a deadlock condition that occurs when attempting to disable aRFS while holding the `priv->state_lock`. The problem arises from a circular locking dependency where the `cancel_work_sync` function is used to cancel scheduled aRFS work items, yet the work handler itself attempts to acquire the same `state_lock` that is already held by the disabling process. This creates an unavoidable deadlock scenario, as the system waits indefinitely for a lock that cannot be acquired due to the circular dependency.
The technical flaw stems from improper synchronization mechanisms within the mlx5e driver's aRFS implementation. When `mlx5e_arfs_disable` is called, it attempts to cancel pending aRFS work items using `cancel_work_sync`, which blocks until the work completes. However, the work handler `arfs_handle_work` is designed to acquire `state_lock` to delete rules, assuming the state is down, but this responsibility should not fall to the worker thread during shutdown. The worker thread operates under the assumption that it can safely acquire locks, leading to the deadlock when it attempts to reacquire `state_lock` that is already owned by the disabling function. This situation is classified under CWE-362, which deals with race conditions and improper lock acquisition patterns in concurrent programming. The circular locking dependency is further exacerbated by the complex call chain involving ethtool operations, netlink communication, and kernel network subsystem interactions, making this vulnerability particularly challenging to resolve without careful lock ordering.
The operational impact of this vulnerability is significant for systems utilizing Mellanox ConnectX network adapters with the mlx5e driver. When aRFS is disabled, typically through ethtool commands or channel configuration changes, the system may become unresponsive or crash entirely due to the deadlock. This can result in complete network service disruption, requiring system reboots to recover. The vulnerability is particularly concerning in high-availability environments where network reliability is critical, as the deadlock can occur during routine operations such as channel configuration changes or driver updates. The issue affects the Linux kernel versions that include the mlx5e driver with aRFS support, making it a widespread concern for enterprise and data center environments using Mellanox hardware. The ATT&CK framework's T1489 technique for "Boot or System Recovery" is relevant here, as the system may require manual intervention or reboot to recover from the deadlock state.
The mitigation for this vulnerability requires modifications to the aRFS implementation to properly track the aRFS state and prevent work items from attempting to modify network rules when aRFS is in the process of being disabled. The fix involves introducing a dedicated state variable to indicate whether aRFS is enabled, ensuring that work items do not attempt to add or delete rules when the system is transitioning to a disabled state. This approach prevents the worker thread from acquiring `state_lock` during shutdown operations, thereby eliminating the circular dependency. The solution aligns with best practices for concurrent programming by ensuring proper lock ordering and avoiding nested lock acquisitions that could lead to deadlocks. Additionally, the fix should include proper state validation within work handlers to ensure that rule modifications only occur when the aRFS subsystem is in a consistent state. This prevents the scenario where a work item attempts to clean up rules while the main disabling function is already holding the lock, thus maintaining system stability and preventing the deadlock condition that can affect network operations. The fix also reinforces the principle of lock discipline, ensuring that locks are held for minimal time and that acquisition order is consistent across all code paths.