CVE-2026-43234

What it actually does

This is a local denial-of-service flaw in the Linux kernel team network driver. When a slave interface is removed or moved across network namespaces during team-device teardown, the team driver can emit a NETDEV_CHANGEMTU notification while the slave is being unregistered. That notification can cause IPv4 device state to take an extra netdev reference during unregister, leaving the device with a nonzero usage count. The result is a stuck unregister path, leaked network-device references, hung cleanup of network namespaces or virtual interfaces, and potentially persistent kernel task stalls affecting network management operations. The CVSS vector indicates local access with low privileges and no user interaction, with high availability impact and no direct confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can make affected Linux systems hang or degrade during network interface or namespace cleanup, disrupting workloads that rely on containers, virtual networking, test automation, CI runners, or dynamic network provisioning. Systems using the kernel team driver are most relevant, but exposure may also exist where unprivileged user namespaces or delegated network administration allow local users or containers to create and manipulate network devices. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no known public exploit maturity in the provided data, so urgency is mainly driven by local multi-tenant risk and operational dependence on Linux network namespace cleanup.

How an attack unfolds

An attacker needs local ability to issue netlink network-configuration operations, typically through CAP_NET_ADMIN in the initial namespace or inside a permitted user/network namespace. They create a team device, attach a slave interface with a specific MTU, create or use another network namespace, move the slave device into that namespace, and then delete the slave device. During this sequence, the team driver unregisters the slave but also triggers an MTU-change notification at the wrong time. Kernel notifier handling initializes or touches IPv4 per-device state and takes a netdev reference, leaving the unregistering device with an outstanding reference. The kernel then waits for the netdev to become free, producing unregister_netdevice/ref_tracker diagnostics and potentially hanging network teardown or accumulating stuck resources. There is no indication from the provided data that remote attackers can exploit this directly, and no named threat actors are associated with it.

How to fix it

Upgrade the Linux kernel to a vendor-supported build that includes the team-driver fix to avoid emitting NETDEV_CHANGEMTU while unregistering a slave device. No exact fixed package versions were provided, so use distribution security advisories and kernel changelogs to identify builds containing the upstream fix for the team driver analogous to the prior bonding-driver correction. Where immediate patching is not possible, reduce exposure by restricting CAP_NET_ADMIN, disabling unprivileged user namespaces where operationally feasible, preventing untrusted users or containers from creating network namespaces and team devices, and avoiding use of the team driver on systems where it is not required. Consider blacklisting or not loading the team kernel module if team networking is unused, after validating there is no production dependency.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version matches a vendor release that includes the fix, not merely that an updated package is installed. Check whether the team module is present or loaded using standard module inventory tools, and review whether local users or containers can obtain CAP_NET_ADMIN or create user/network namespaces. In a controlled nonproduction environment only, attempt the published reproducer pattern: create a team interface, attach a dummy slave with a nondefault MTU, create a network namespace, move the slave into it, and delete the slave. A fixed kernel should complete cleanup without unregister_netdevice wait messages, ref_tracker netdev leaks, hung task reports, or persistent network namespace cleanup stalls. Do not run destructive reproducers on production systems.

Typical attack path

1. Obtain local access to a Linux system with permission to create or manipulate network devices, commonly CAP_NET_ADMIN or equivalent permissions inside an enabled user/network namespace.
2. Create a team interface using the kernel team driver.
3. Create or attach a slave network interface to the team device, potentially with a nondefault MTU.
4. Create a separate network namespace.
5. Move the slave interface into the new namespace while it is still associated with the team device lifecycle.
6. Delete the slave interface from that namespace.
7. Trigger the vulnerable unregister path, causing a NETDEV_CHANGEMTU notification during slave unregister and leaving a netdev reference held.
8. Cause network-device cleanup to hang or consume kernel resources, resulting in denial of service or operational disruption.

How to detect it

Look for evidence in kernel logs, system journals, audit logs, and container/runtime logs showing network-device manipulation immediately followed by kernel unregister or reference-tracker warnings. Primary log sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, auditd records for iproute2 or netlink operations, sudo logs, shell history where available, and container orchestration audit logs showing privileged containers or CAP_NET_ADMIN grants. Suspicious sequences include creation of team devices, dummy interfaces, network namespaces, moving interfaces between namespaces, and deleting those interfaces, followed by kernel messages such as unregister_netdevice waiting for a device to become free, ref_tracker netdev reports, or stack traces mentioning team_port_del, team_device_event, dev_set_mtu, netif_set_mtu, inetdev_init, or rtnl_newlink. Because exploitation is local and primarily causes availability impact, there may be no network IOC. Focus detection on repeated local invocations of ip link/ip netns commands, unexpected loading or use of the team driver, privileged container starts, and kernel task stalls correlated with network namespace teardown.

• unregister_netdevice: waiting for
• Usage count =
• ref_tracker: netdev@
• team_port_del
• team_device_event
• NETDEV_CHANGEMTU
• inetdev_init
• inetdev_event
• netif_set_mtu
• dev_set_mtu
• rtnl_newlink
• netlink_sendmsg
• ip link add name team
• type team
• ip link add name dummy
• type dummy
• ip netns add
• ip link set dev
• netns
• ip -n
• link del dev
• drivers/net/team/team_core.c

What your security team should do

• Prioritize patching Linux systems that allow local untrusted users, shared shell access, CI jobs, containers, Kubernetes workloads with elevated networking permissions, or any workload with CAP_NET_ADMIN.
• Inventory systems using or loading the team driver and determine whether team networking is required; remove or disable it where unnecessary.
• Restrict CAP_NET_ADMIN and privileged container execution, and review policies that allow user namespaces or network namespace creation by untrusted principals.
• Monitor kernel logs for unregister_netdevice waits, ref_tracker netdev messages, and stack traces involving team_port_del or team_device_event.
• Use compensating controls on multi-tenant hosts before broad kernel rollout: block untrusted creation of team devices, dummy devices, and network namespaces where possible.
• Schedule kernel reboots after installing fixed packages, because the vulnerable code remains active until the fixed kernel is running.
• Treat evidence of repeated local network namespace/device manipulation followed by kernel unregister stalls as potential attempted denial of service, even though no public exploitation or KEV status is reported.