CVE-2026-43199

What it actually does

This is a Linux kernel denial-of-service flaw in the Mellanox/NVIDIA mlx5 Ethernet driver IPsec acceleration path. During IPsec-related event handling, the driver calls a hardware MAC-address query routine that can sleep while executing in an atomic context. That invalid context transition triggers a kernel "scheduling while atomic" bug, which can destabilize the affected kernel and may lead to a kernel warning, stalled worker, driver malfunction, or system crash depending on kernel configuration and runtime conditions. The impact is availability only; the provided details do not indicate confidentiality loss, integrity modification, privilege escalation, or code execution.

Why it matters to the business

Organizations running affected Linux kernels on systems using mlx5 network adapters and IPsec offload features may experience network disruption or host instability. The most likely business consequence is service interruption on servers, appliances, hypervisors, or network-facing workloads that depend on affected NICs. Although the CVSS availability impact is high, this issue is not currently listed in CISA KEV, has no known ransomware association, has no reported exploit maturity, and has a low, flat EPSS score, so prioritization should focus on exposed high-availability systems using mlx5 hardware and IPsec acceleration rather than broad emergency response.

How an attack unfolds

An attacker would need to cause the vulnerable mlx5 IPsec event path to execute on a system with an affected kernel, mlx5 driver, compatible hardware, and IPsec acceleration in use or reachable through configuration. The vulnerable path attempts to initialize IPsec MAC attributes and queries the NIC hardware for a MAC address through mlx5_cmd_exec(), a command path that can sleep. Because this occurs from an atomic-context workqueue path, the kernel detects an invalid sleep attempt and emits a "BUG: scheduling while atomic" condition. Repeated triggering could degrade network processing, disrupt IPsec-accelerated traffic, or crash the host depending on kernel panic settings, watchdog behavior, and driver recovery. There is no evidence in the provided intelligence that exploitation enables remote code execution or data theft.

How to fix it

Apply a Linux kernel update from the relevant distribution, appliance vendor, or upstream stable kernel that includes the mlx5e IPsec MAC initialization fix. The corrected behavior avoids querying hardware from atomic context and instead uses the MAC address already present in netdev->dev_addr via ether_addr_copy(). No exact fixed package versions were provided, so remediation should be tracked through vendor advisories and kernel changelogs referencing "net/mlx5e: Fix scheduling while atomic in IPsec MAC address query" or equivalent backports. Where immediate patching is not possible, reduce risk by disabling mlx5 IPsec hardware offload where operationally acceptable, avoiding affected driver/kernel combinations on critical network paths, and ensuring HA/failover capacity for systems using affected mlx5 adapters.

How to confirm the fix worked

Confirm that the running kernel package or vendor firmware/software bundle includes the backported mlx5e IPsec fix. Validate through distribution advisories, kernel changelogs, or source inspection showing mlx5e_ipsec_init_macs() no longer calls mlx5_query_mac_address() for the local MAC and instead copies from netdev->dev_addr. On running systems, verify the active kernel version after reboot, confirm mlx5 modules were reloaded as part of the patched kernel, and review dmesg/journal logs after IPsec activity for absence of "BUG: scheduling while atomic" traces involving mlx5e_ipsec_init_macs, mlx5_query_mac_address, or mlx5_cmd_exec. If IPsec offload was disabled as a mitigation, verify the offload setting remains disabled and that traffic continues to use the intended software or alternate path.

Typical attack path

1. Identify a Linux host or appliance using an affected kernel with mlx5_core/mlx5e networking and IPsec acceleration support.
2. Send or induce traffic or state changes that cause the mlx5e IPsec event-handling path to process IPsec acceleration attributes.
3. Trigger mlx5e_ipsec_handle_event() and mlx5e_ipsec_init_macs() so the driver attempts a hardware MAC address query from an atomic context.
4. Cause the kernel to hit a "scheduling while atomic" condition when mlx5_cmd_exec() attempts to sleep.
5. Repeat the trigger to cause service degradation, network instability, or a host-level denial of service.

How to detect it

Look for evidence of attempted or successful denial of service in kernel logs, system journals, crash dumps, and monitoring telemetry. Primary sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, kdump/vmcore analysis, kernel oops/panic collectors, NIC driver telemetry, and availability monitoring around affected hosts. The most relevant artifacts are kernel traces containing "BUG: scheduling while atomic" with mlx5_core, mlx5e_ipsec_init_macs(), mlx5e_ipsec_handle_event(), mlx5_query_mac_address(), mlx5_query_nic_vport_mac_address(), mlx5_cmd_exec(), or cmd_exec(). Correlate those events with IPsec tunnel establishment, rekeying, interface changes, XFRM state/policy changes, or bursts of encrypted traffic. Since this flaw is a kernel bug and not malware, there may be no attacker-created files, processes, registry keys, or persistent host artifacts. Treat matching traces as evidence of exposure or triggering; determine maliciousness by correlating with remote peer activity, unusual IPsec negotiation patterns, repeated crashes, and timing of service degradation.

• BUG: scheduling while atomic
• mlx5e_ipsec_init_macs
• mlx5e_ipsec_handle_event
• mlx5e_ipsec_build_accel_xfrm_attrs
• mlx5_query_mac_address
• mlx5_query_nic_vport_mac_address
• mlx5_cmd_exec
• cmd_exec+0xa85/0xff0 [mlx5_core]
• [mlx5_core]
• kworker/u112:2
• process_one_work
• worker_thread
• net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query

What your security team should do

• Inventory Linux systems using Mellanox/NVIDIA mlx5 adapters, especially servers using IPsec hardware offload or encrypted network overlays.
• Prioritize kernel updates for internet-facing, high-availability, storage, virtualization, and network appliance roles that rely on mlx5 networking.
• Track vendor advisories for the exact fixed kernel builds because no fixed versions were provided in the input intelligence.
• If patching is delayed, consider disabling mlx5 IPsec hardware offload where feasible and test performance impact before production rollout.
• Search kernel logs for historical "scheduling while atomic" traces involving mlx5_core, mlx5e_ipsec_init_macs, mlx5_query_mac_address, and mlx5_cmd_exec.
• Do not treat this as a compromise indicator by itself; correlate crashes or kernel BUGs with external traffic patterns, IPsec state changes, and service disruption.
• Because EPSS is low and flat and the issue is not KEV-listed, prioritize based on actual exposure to affected mlx5/IPsec configurations rather than CVSS score alone.