CVE-2024-58071 in Linux
Summary
by MITRE • 03/06/2025
In the Linux kernel, the following vulnerability has been resolved:
team: prevent adding a device which is already a team device lower
Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1.
This is not useful in practice and can lead to recursive locking:
$ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0
============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by ip/7684:
stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace:
dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/16/2026
The vulnerability identified as CVE-2024-58071 resides within the Linux kernel's team driver implementation, specifically in how it handles device attachment operations. This flaw allows for the addition of a network device to a team interface even when that device is already a lower device of another team device, creating a recursive dependency that leads to a deadlock scenario. The issue manifests when a device hierarchy is constructed such as a virtual ethernet pair where one end is used as a lower device for a vlan interface, which is then added to a team device, and subsequently the original device is added to the same team. This creates a circular reference in the kernel's locking mechanism, as the team driver attempts to acquire a lock it already holds, resulting in a deadlock condition that can cause system instability or denial of service.
The technical root cause of this vulnerability is found in the team driver's lack of proper validation during the device addition process. According to the Linux kernel's locking subsystem and the lockdep framework, the team driver uses a mutex lock named team_lock_key to synchronize access to its internal data structures. When a device is added to a team, the driver performs operations that require acquiring this lock. However, it does not check if the device being added is already a lower device of another team device, which leads to recursive lock acquisition. This recursive locking scenario violates kernel locking best practices and is categorized under CWE-367, which deals with Time-of-Check to Time-of-Use (TOCTOU) vulnerabilities. The specific locking violation occurs in the team_device_event function, which is triggered when network device events are processed, and the recursive acquisition is detected by the kernel's lock dependency tracking system.
The operational impact of this vulnerability is significant as it can lead to system crashes or complete system lockups when malicious or malformed network configuration commands are executed. Attackers could exploit this by crafting network device configurations that result in the recursive locking condition, potentially causing a denial of service against the entire system. The vulnerability is particularly dangerous in environments where network configuration is managed dynamically or by untrusted users, as it allows for a simple configuration command to trigger a kernel-level deadlock. From an ATT&CK perspective, this vulnerability maps to T1499.004, which involves network denial of service attacks, and T1059.008, which involves command and scripting interpreters, as the vulnerability can be exploited through network configuration commands. The system's stability is compromised because the kernel's lockdep subsystem detects the deadlock condition and issues warnings, indicating that the system is in an unsafe locking state.
Mitigation strategies for this vulnerability involve implementing proper validation checks within the team driver's device addition logic to prevent the addition of devices that are already lower devices of other team interfaces. The fix requires modifying the team_add_slave function to include a check that identifies if a device is already part of another team's lower device hierarchy before attempting to add it to a new team. This aligns with the principle of least privilege and defense in depth, ensuring that kernel subsystems validate inputs thoroughly. System administrators should ensure that all systems running affected kernel versions are updated with patches that implement this validation. Additionally, monitoring for lockdep warnings can help detect potential exploitation attempts. The fix should be incorporated into kernel security hardening practices and can be validated through regression testing that includes complex device hierarchy configurations to ensure that recursive locking scenarios are properly prevented.