CVE-2026-43199: net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query
Fix a "scheduling while atomic" bug in mlx5eipsecinitmacs() by replacing mlx5querymacaddress() with etheraddrcopy() to get the local MAC address directly from netdev->devaddr.
The issue occurs because mlx5querymacaddress() queries the hardware which involves mlx5cmdexec() that can sleep, but it is called from the mlx5eipsechandleevent workqueue which runs in atomic context.
The MAC address is already available in netdev->devaddr, so no need to query hardware. This avoids the sleeping call and resolves the bug.
Call trace: BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200 schedule+0x7ab/0xa20 schedule+0x1c/0xb0 scheduletimeout+0x6e/0xf0 waitforcommon+0x91/0x1b0 cmdexec+0xa85/0xff0 [mlx5core] mlx5cmdexec+0x1f/0x50 [mlx5core] mlx5querynicvportmacaddress+0x7b/0xd0 [mlx5core] mlx5querymacaddress+0x19/0x30 [mlx5core] mlx5eipsecinitmacs+0xc1/0x720 [mlx5core] mlx5eipsecbuildaccelxfrmattrs+0x422/0x670 [mlx5core] mlx5eipsechandleevent+0x2b9/0x460 [mlx5core] processonework+0x178/0x2e0 workerthread+0x2ea/0x430
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The issue is in the Linux kernel mlx5e (mlx5_core) driver, specifically the IPsec MAC-address initialization path. Systems not using this driver or its IPsec event handling path are not indicated as affected by the provided information.
What conditions lead to the failure?
The failure occurs when mlx5e_ipsec_init_macs() calls mlx5_query_mac_address() from the mlx5e_ipsec_handle_event workqueue. That hardware query can sleep through mlx5_cmd_exec(), but the workqueue context is atomic, producing a "scheduling while atomic" condition.
What is the practical impact?
The reported impact is an availability problem: the kernel can trigger a "scheduling while atomic" bug in the affected driver path. The supplied CVSS vector rates this as network-reachable, low-complexity, requiring no privileges or user interaction, with high availability impact and no stated confidentiality or integrity impact.
What does the fix change?
The fix stops querying the hardware for the local MAC address in this path. It instead copies the already available address from netdev->dev_addr with ether_addr_copy(), avoiding the sleep-capable command execution.