CVE-2026-43012

What it actually does

This flaw is a local denial-of-service condition in the Linux kernel Mellanox mlx5 network driver switchdev/e-switch handling path. When a privileged or partially privileged local user requests a devlink transition into switchdev mode and that transition fails internally, the driver incorrectly rolls back to legacy mode without setting the rollback state that prevents unregistering the uplink netdevice. The bad rollback path can leave the uplink representor unregistered and trigger a kernel BUG in net/core/dev.c during netdevice unregister handling, causing a kernel oops/panic or loss of networking availability depending on kernel panic policy and runtime configuration. The issue affects systems using mlx5-capable Mellanox/NVIDIA ConnectX-class hardware and the Linux mlx5 driver with devlink e-switch mode operations; it is not a remote code execution or data disclosure vulnerability.

Why it matters to the business

Exploitation can crash or destabilize affected Linux hosts that use mlx5 networking features, causing workload interruption, node loss, failed network connectivity, or service failover events. The practical risk is highest for virtualization, container, NFV, SDN, and high-performance compute environments that expose devlink or SR-IOV/switchdev administration to local operators or automation. The CVSS score is moderate, EPSS is very low and stable, it is not listed in CISA KEV, and no exploit maturity is reported, so broad opportunistic exploitation is unlikely; however, the operational impact can still be severe on systems where a local user, compromised process, or misbehaving automation can change mlx5 e-switch mode.

How an attack unfolds

An attacker first needs local access with enough privileges to send devlink generic netlink requests that modify the mlx5 e-switch mode, typically requiring root or capabilities such as CAP_NET_ADMIN in the relevant namespace. The attacker identifies an mlx5-backed PCI device and invokes a devlink operation to set the e-switch mode to switchdev. If the switchdev enablement path fails because of device state, unsupported capabilities, firmware response, or another internal error, vulnerable kernels enter the rollback path. Because the driver fails to mark rollback as legacy mode before unloading the uplink representor, the rollback attempts to unregister a netdevice that is already in an inconsistent state. This triggers a kernel BUG in unregister_netdevice_many_notify(), resulting in a kernel oops or panic and denying service on the affected host. Exploitation is local, does not require user interaction, and primarily impacts availability.

How to fix it

Upgrade to a Linux kernel version that includes the upstream mlx5 fix for switchdev mode rollback. Because no exact fixed package versions were provided, use the fixed kernel builds published by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer, and verify that the patch for "net/mlx5: Fix switchdev mode rollback in case of failure" is included. Prioritize systems with Mellanox/NVIDIA mlx5 hardware, SR-IOV, switchdev, devlink, Open vSwitch offload, Kubernetes/virtualization networking, or NFV workloads. If immediate patching is not possible, restrict devlink and network administration privileges, remove unnecessary CAP_NET_ADMIN from containers and services, limit root access, disable or avoid switchdev mode transitions where operationally feasible, and ensure host reboot/failover procedures are tested. Consider temporarily keeping affected adapters in a stable legacy mode until patched if switchdev is not required.

How to confirm the fix worked

Confirm exposure by checking whether the system runs an affected Linux kernel with the mlx5_core driver loaded and has mlx5 PCI devices managed through devlink. Commands commonly used for validation include checking kernel package/changelog entries for the named mlx5 rollback fix, reviewing `uname -r`, confirming loaded modules with `lsmod | grep mlx5`, and listing devices with `devlink dev show`. Confirm remediation by verifying the installed kernel package contains the vendor fix and by rebooting into the fixed kernel. On non-production test systems only, validate that failed switchdev transitions no longer produce a kernel BUG or unregister-related oops; do not intentionally trigger this on production systems. Also verify that untrusted users, containers, and services do not retain CAP_NET_ADMIN or access to host devlink operations unless required.

Typical attack path

1. Gain local shell, container escape context, administrative automation access, or another local execution path on a Linux system using the mlx5 kernel driver.
2. Obtain sufficient privileges to perform devlink e-switch configuration changes, commonly root or CAP_NET_ADMIN.
3. Enumerate devlink devices and identify an mlx5 PCI device with e-switch support.
4. Issue a devlink request to switch the device into switchdev mode.
5. Cause or rely on an internal switchdev enablement failure, such as unsupported capability, incompatible device state, or firmware command failure.
6. Trigger the vulnerable rollback path that unloads the uplink representor incorrectly.
7. Crash the kernel or destabilize networking through a kernel BUG/oops, causing denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs and persistent journal data for devlink-initiated mlx5 e-switch mode changes followed by mlx5 command failures, uplink representor unloads, and a kernel BUG/oops in the netdevice unregister path. Relevant sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump tooling such as kdump/vmcore, console logs, hypervisor out-of-band logs, and EDR telemetry for devlink command execution. Look for process context showing `Comm: devlink`, generic netlink/devlink calls, `mlx5_devlink_eswitch_mode_set`, `devlink_nl_eswitch_set_doit`, and stack traces ending in `unregister_netdevice_many_notify`, `unregister_netdev`, or `mlx5e_vport_rep_unload`. Correlate these events with local user sessions, sudo logs, container runtime events, orchestration jobs, and network automation runs that executed `devlink dev eswitch set ... mode switchdev`. Because the vulnerability is a crash/availability issue, evidence may be limited after reboot unless persistent kernel logging or crash dumps are enabled.

• Comm: devlink
• kernel BUG at net/core/dev.c
• unregister_netdevice_many_notify
• unregister_netdevice_queue
• unregister_netdev
• mlx5e_vport_rep_unload
• esw_offloads_enable
• mlx5_eswitch_enable_locked
• mlx5_devlink_eswitch_mode_set
• devlink_nl_eswitch_set_doit
• mlx5_core
• E-Switch: Disable: mode(LEGACY)
• Loading uplink representor for vport 65535
• Unloading uplink representor for vport 65535
• mlx5_cmd_out_err
• QUERY_HCA_CAP(0x100)
• status bad parameter(0x3)
• syndrome (0x3a3846)
• enp0s3np0 (unregistered)
• Oops: invalid opcode
• devlink dev eswitch set
• mode switchdev

What your security team should do

• Inventory Linux systems using Mellanox/NVIDIA mlx5 adapters, SR-IOV, switchdev, or devlink-managed networking and prioritize them for kernel updates.
• Apply vendor-provided fixed kernel packages or kernel live patches where available; reboot into the fixed kernel where required.
• Restrict devlink and e-switch mode changes to trusted administrative workflows only; remove unnecessary CAP_NET_ADMIN from containers and services.
• Review automation that changes mlx5 e-switch mode and pause risky switchdev transitions until affected hosts are patched.
• Monitor kernel logs for mlx5 switchdev rollback failures, uplink representor unloads, and kernel BUG/oops events involving unregister_netdevice_many_notify.
• Ensure high-availability, node drain, and failover procedures are ready for hosts that cannot be patched immediately.
• Track distribution advisories for exact fixed kernel versions because no universal fixed version was provided in the input.