CVE-2026-43467

What it actually does

This flaw is a local denial-of-service vulnerability in the Linux kernel Mellanox/NVIDIA mlx5 network driver path used when changing an mlx5 device into switchdev mode. On devices that do not support IPsec, the driver incorrectly attempts to clean up IPsec-related resources during the mode transition. That invalid cleanup path can dereference invalid or uninitialized state, causing a kernel warning/page fault and potentially a kernel crash or system instability. The issue requires local privileges sufficient to invoke the relevant devlink/eswitch configuration path and does not provide confidentiality or integrity impact based on the available information.

Why it matters to the business

Systems using mlx5-based network adapters may crash or become unstable during network mode changes, potentially interrupting host networking, container or virtualization networking, storage-over-network traffic, or workloads dependent on RDMA/SmartNIC features. Because exploitation requires local privileged access and there is no known public exploitation or KEV listing, broad internet-facing risk is low; however, the operational impact can be high on hosts where mlx5 switchdev mode is used for SR-IOV, offload, Kubernetes networking, NFV, or high-performance networking.

How an attack unfolds

An attacker who already has local access with privileges to manage network device configuration can identify a host with an affected Linux kernel and an mlx5 device that lacks IPsec support. The attacker then uses devlink or equivalent netlink operations to move the device into switchdev mode. During the transition, the mlx5 driver enters the eswitch offload setup path and attempts to disable or clean up IPsec event resources even though those resources are not supported or initialized. This triggers a fault in the kernel, leading to a warning, page fault, driver failure, or system crash. The practical result is denial of service rather than code execution.

How to fix it

Apply a Linux kernel update that includes the mlx5 fix for checking IPsec capability before attempting to clean up IPsec resources during switchdev transition. If vendor fixed package versions are not yet available, track the relevant distribution kernel advisories for this issue and update to the first kernel build containing the upstream mlx5 correction. As interim mitigations, restrict local administrative access, limit CAP_NET_ADMIN and devlink access to trusted operators only, avoid switching affected mlx5 devices into switchdev mode on devices without IPsec support, and schedule any required switchdev transitions during maintenance windows. Where feasible, disable or unload unused mlx5 functionality on systems that do not require it, recognizing that this may disrupt networking or RDMA features.

How to confirm the fix worked

Confirm that the running kernel includes the vendor or upstream fix for the mlx5 switchdev/IPsec cleanup path. Validate package remediation through the operating system package manager and by confirming the active booted kernel is the updated kernel, not merely installed. On systems using mlx5 hardware, verify that changing eswitch mode no longer produces kernel warnings, page faults, or mlx5_core stack traces. Review dmesg, journald, and kernel logs after testing for absence of faults involving mlx5e_ipsec_disable_events, mlx5e_nic_disable, mlx5_devlink_eswitch_mode_set, or devlink_nl_eswitch_set_doit. Also verify that access to devlink and CAP_NET_ADMIN is limited to intended administrators or service accounts.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with the mlx5 driver loaded.
2. Obtain privileges capable of changing devlink/eswitch settings, typically root or CAP_NET_ADMIN-equivalent permissions.
3. Confirm the presence of an mlx5 device and that the device does not support IPsec offload.
4. Invoke a devlink operation to move the mlx5 device into switchdev mode.
5. Trigger the vulnerable cleanup path in the mlx5 driver during the mode transition.
6. Cause a kernel fault, warning, driver instability, or host crash, resulting in denial of service.

How to detect it

To determine whether this was already triggered, review kernel and system logs for crashes or warnings involving mlx5, devlink, eswitch, switchdev, and IPsec cleanup paths. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel logs, crash dump tooling such as kdump/vmcore, and EDR telemetry for privileged devlink executions. Correlate any kernel fault with nearby commands or audit events showing use of devlink to set eswitch mode, especially transitions to switchdev. Look for stack traces containing mlx5e_ipsec_disable_events, mlx5e_nic_disable, mlx5e_detach_netdev, mlx5e_netdev_change_profile, mlx5_devlink_eswitch_mode_set, devlink_nl_eswitch_set_doit, or page faults in _raw_spin_lock_irqsave/complete_all. Also review Linux audit logs for executions of the devlink binary or netlink operations by unexpected users, administrators, automation, or privileged containers. A single occurrence may indicate accidental operational triggering; repeated or suspiciously timed occurrences may indicate intentional denial-of-service activity.

• mlx5e_ipsec_disable_events
• mlx5e_nic_disable
• mlx5e_detach_netdev
• mlx5e_netdev_change_profile
• mlx5e_vport_rep_load
• mlx5_devlink_eswitch_mode_set
• devlink_nl_eswitch_set_doit
• esw_offloads_enable
• mlx5_eswitch_enable_locked
• mlx5_esw_offloads_rep_load
• __esw_offloads_load_rep
• _raw_spin_lock_irqsave+0x10/0x30
• complete_all+0x20/0x90
• do_user_addr_fault+0x18a/0x680
• asm_exc_page_fault+0x22/0x30
• Comm: devlink
• Modules linked in:
• mlx5_core
• mlx5_ib
• mlx5_fwctl
• devlink
• switchdev
• eswitch
• devlink dev eswitch set
• mode switchdev

What your security team should do

• Inventory Linux hosts with mlx5_core loaded or Mellanox/NVIDIA ConnectX/mlx5-class devices, prioritizing virtualization, Kubernetes, NFV, RDMA, and SmartNIC-enabled systems.
• Patch affected hosts to a kernel version containing the mlx5 fix as soon as vendor packages are available, prioritizing systems where switchdev mode is used or can be changed by local operators.
• Restrict root, sudo, CAP_NET_ADMIN, and container privileges that allow devlink or network device mode changes.
• Monitor kernel logs for mlx5_core crashes or stack traces after devlink eswitch mode changes.
• Avoid nonessential switchdev mode transitions on potentially affected devices until patched.
• Ensure rollback and out-of-band management procedures are available for high-availability hosts before network driver or kernel maintenance.
• Because EPSS is very low and there is no KEV or known exploit maturity, prioritize based on exposure to local privileged users and operational criticality rather than internet-facing exploitability.