CVE-2026-43167

What it actually does

This Linux kernel flaw affects the XFRM/IPsec hardware offload path during network device unregistration. A local user with sufficient privileges to configure XFRM state and manipulate a network device can create an IPsec offload state that holds a reference to a net_device, then trigger device unregister after offload capabilities change. Because the kernel did not always flush related XFRM state and policy on NETDEV_UNREGISTER, the net_device reference can leak. The result is a denial-of-service condition where device teardown can hang with elevated usage counts, potentially leaving kernel resources stuck and affecting network device lifecycle operations.

Why it matters to the business

Successful exploitation can disrupt Linux systems that use IPsec/XFRM or network device offload features by causing network device removal or reconfiguration to hang. In production, this may interfere with network interface lifecycle management, container or virtual network teardown, test infrastructure, VPN/IPsec operations, or host maintenance workflows. The issue requires local privileges and has very low current EPSS activity, is not listed in CISA KEV, and has no known exploit maturity reported, so it is lower urgency than remotely exploitable kernel flaws but still important for multi-user, container-hosting, lab, CI, and network appliance environments.

How an attack unfolds

An attacker first obtains local access with privileges sufficient to create XFRM/IPsec state and manipulate a network device or simulated network device. They create an XFRM security association using ESP hardware offload against a selected interface, causing the XFRM device path to acquire a reference to the underlying net_device. They then change the interface feature state, such as disabling ESP hardware offload, and unregister or remove the network device. On vulnerable kernels, the NETDEV_UNREGISTER handling does not unconditionally flush all related XFRM state and policy, so the net_device reference is not released. The unregister operation can then wait indefinitely or leave kernel resources pinned, producing a local denial of service against networking operations or system cleanup paths.

How to fix it

Apply a Linux kernel update that includes the upstream fix to always flush XFRM state and policy when a NETDEV_UNREGISTER event occurs. No exact fixed package versions were provided in the input, so remediation should be performed by updating to the latest vendor-supported kernel for the relevant distribution or appliance platform and confirming that the vendor advisory for CVE-2026-43167 is included. Where immediate patching is not possible, reduce exposure by limiting local administrative capabilities that allow XFRM state creation, IPsec offload configuration, ethtool offload changes, network namespace administration, and network device creation/removal. Avoid enabling untrusted users or workloads to run with CAP_NET_ADMIN or equivalent privileges. Consider disabling or restricting IPsec/ESP hardware offload on systems where it is not operationally required, and harden container runtimes so containers cannot manipulate host networking devices or XFRM policy.

How to confirm the fix worked

Confirm the running kernel package is updated to a vendor release that includes the XFRM NETDEV_UNREGISTER flushing fix. Validate exposure by checking whether untrusted users, containers, or automation have CAP_NET_ADMIN or equivalent permission to create XFRM state and manipulate network devices. On test systems only, administrators can verify the fix by reproducing the XFRM offload plus device unregister sequence described in the advisory and confirming that device removal completes cleanly without kernel messages such as 'unregister_netdevice: waiting for ... to become free' or ref_tracker reports involving xfrm_dev_state_add. Also confirm that IPsec/XFRM functionality and network interface teardown continue to work after patching.

Typical attack path

1. Gain local access to a Linux system with privileges to configure XFRM/IPsec state and manipulate network devices.
2. Identify or create a network interface that supports or exposes ESP/IPsec hardware offload behavior, including simulated devices in test-capable environments.
3. Add an XFRM/IPsec ESP state with hardware offload bound to that interface.
4. Disable or alter the interface offload feature state after the XFRM state has acquired a device reference.
5. Unregister, delete, or remove the affected network device.
6. Trigger a leaked net_device reference, causing device teardown to hang or kernel resources to remain pinned.

How to detect it

Look for evidence of failed or hanging network device teardown combined with XFRM/IPsec offload configuration activity. Useful log sources include kernel logs from dmesg, journald kernel facility, syslog/kern.log, auditd command execution logs, EDR process telemetry, container runtime audit logs, and shell history where available. Key artifacts include kernel messages showing unregister_netdevice waiting for an interface to become free, ref_tracker reports involving xfrm_dev_state_add or xfrm_state_construct, and recent use of commands that add XFRM state with offload, change ESP hardware offload with ethtool, or create/delete netdevsim devices. Investigate any sequence where 'ip xfrm state add ... offload crypto dev ...' is followed by 'ethtool -K ... esp-hw-offload off' and then interface deletion or device unregistration. Also review whether the activity originated from unexpected users, containers, CI jobs, or workloads with CAP_NET_ADMIN.

• unregister_netdevice: waiting for
• Usage count =
• ref_tracker: netdev@
• xfrm_dev_state_add
• xfrm_state_construct
• xfrm_add_sa
• xfrm_user_rcv_msg
• xfrm_netlink_rcv
• NETDEV_UNREGISTER
• ip xfrm state add
• offload crypto dev
• proto esp
• ethtool -K
• esp-hw-offload off
• /sys/bus/netdevsim/new_device
• /sys/bus/netdevsim/del_device
• /sys/bus/netdevsim/devices/
• netdevsim0

What your security team should do

• Prioritize patching Linux systems that host containers, CI workloads, network simulation, VPN/IPsec services, or users with local administrative/network privileges.
• Inventory systems where CAP_NET_ADMIN is granted to non-root users, containers, pods, CI jobs, or automation, and reduce those grants where possible.
• Update affected Linux kernels through the operating system or appliance vendor as soon as a fixed release is available for the platform.
• Monitor kernel logs for net_device reference leaks, stuck unregister operations, and XFRM/IPsec offload activity.
• Restrict access to network device creation/removal interfaces and tools such as ip, ethtool, and netdevsim to trusted administrators only.
• If patching is delayed, disable unnecessary ESP/IPsec hardware offload capabilities and avoid exposing netdevsim or similar test interfaces on production systems.
• Because this issue is not in KEV, has no reported exploit maturity, and EPSS remains very low, track it through normal kernel maintenance unless local privilege boundaries are weak or multi-tenant workloads are present.