CVE-2024-35959 in Linux
Summary
by MITRE • 05/20/2024
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix mlx5e_priv_init() cleanup flow
When mlx5e_priv_init() fails, the cleanup flow calls mlx5e_selq_cleanup which calls mlx5e_selq_apply() that assures that the `priv->state_lock` is held using lockdep_is_held().
Acquire the state_lock in mlx5e_selq_cleanup().
Kernel log: ============================= WARNING: suspicious RCU usage 6.8.0-rc3_net_next_841a9b5 #1 Not tainted ----------------------------- drivers/net/ethernet/mellanox/mlx5/core/en/selq.c:124 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 2 locks held by systemd-modules/293: #0: ffffffffa05067b0 (devices_rwsem){++++}-{3:3}, at: ib_register_client+0x109/0x1b0 [ib_core]
#1: ffff8881096c65c0 (&device->client_data_rwsem){++++}-{3:3}, at: add_client_context+0x104/0x1c0 [ib_core]
stack backtrace: CPU: 4 PID: 293 Comm: systemd-modules Not tainted 6.8.0-rc3_net_next_841a9b5 #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+0x8a/0xa0 lockdep_rcu_suspicious+0x154/0x1a0 mlx5e_selq_apply+0x94/0xa0 [mlx5_core]
mlx5e_selq_cleanup+0x3a/0x60 [mlx5_core]
mlx5e_priv_init+0x2be/0x2f0 [mlx5_core]
mlx5_rdma_setup_rn+0x7c/0x1a0 [mlx5_core]
rdma_init_netdev+0x4e/0x80 [ib_core]
? mlx5_rdma_netdev_free+0x70/0x70 [mlx5_core]
ipoib_intf_init+0x64/0x550 [ib_ipoib]
ipoib_intf_alloc+0x4e/0xc0 [ib_ipoib]
ipoib_add_one+0xb0/0x360 [ib_ipoib]
add_client_context+0x112/0x1c0 [ib_core]
ib_register_client+0x166/0x1b0 [ib_core]
? 0xffffffffa0573000 ipoib_init_module+0xeb/0x1a0 [ib_ipoib]
do_one_initcall+0x61/0x250 do_init_module+0x8a/0x270 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x17d/0x230 __x64_sys_finit_module+0x61/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x46/0x4e
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2025
The vulnerability identified as CVE-2024-35959 resides within the Linux kernel's Mellanox 5th generation Ethernet driver component known as mlx5e. This flaw manifests during the initialization process of network interfaces, specifically when the mlx5e_priv_init() function encounters a failure. The issue stems from an improper cleanup sequence where the mlx5e_selq_cleanup() function attempts to invoke mlx5e_selq_apply() without first acquiring the necessary state_lock. This misstep triggers a suspicious RCU (Read-Copy-Update) usage warning, indicating that the kernel's locking subsystem has detected a potential race condition or improper lock acquisition during concurrent access to shared data structures.
The technical root cause lies in the failure to maintain proper locking semantics during error handling paths. According to the kernel log output, the warning originates from drivers/net/ethernet/mellanox/mlx5/core/en/selq.c line 124, where a suspicious rcu_dereference_protected() usage is detected. The lockdep_is_held() check within mlx5e_selq_apply() enforces that the priv->state_lock must be held before proceeding, yet this requirement is not satisfied when mlx5e_selq_cleanup() calls mlx5e_selq_apply(). This violates fundamental locking principles and can lead to undefined behavior, data corruption, or system instability. The stack trace reveals that the issue occurs during module initialization when systemd-modules attempts to register an InfiniBand client, specifically when processing IPoIB (Internet Protocol over InfiniBand) interface creation. The presence of two held locks from ib_core subsystem further indicates the complexity of the locking context during this operation.
The operational impact of this vulnerability extends beyond simple initialization failures, potentially affecting system stability and network functionality. When the mlx5e driver fails to properly initialize, network interfaces may become unavailable or exhibit erratic behavior, particularly in high-performance computing environments that rely heavily on Mellanox hardware. The improper cleanup flow can result in memory leaks, resource contention, or even kernel oops if the RCU subsystem detects the inconsistent locking state. This vulnerability aligns with CWE-691, which addresses insufficient control flow management, and maps to ATT&CK technique T1059.001 for execution through kernel modules. The flaw particularly affects systems using Linux kernel versions 6.8.0-rc3 and later, where the net_next_841a9b5 branch introduces the problematic locking behavior. The vulnerability could be exploited by an attacker who gains the ability to trigger specific module loading sequences, potentially leading to denial of service or privilege escalation in scenarios where kernel module loading is not properly restricted.
The recommended mitigation strategy involves ensuring that the mlx5e_selq_cleanup() function properly acquires the state_lock before invoking mlx5e_selq_apply(). This requires modifying the cleanup flow to include explicit lock acquisition, thereby satisfying the lockdep_is_held() requirement. The fix should be implemented as a patch to the mlx5_core driver module, specifically addressing the error handling path in the mlx5e_priv_init() function. System administrators should apply the latest kernel updates from their distribution or manually patch the affected kernel version. Additionally, monitoring for suspicious RCU usage warnings in kernel logs should be enabled to detect similar issues. The patch should also include proper lock ordering validation to prevent future regressions. Organizations relying on Mellanox networking hardware in production environments must ensure that all systems are updated with the patched kernel version to maintain network reliability and prevent potential exploitation of this locking inconsistency.