Answer in brief
CVE-2026-43199 records a Unknown severity vulnerability in net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=cee137a634318bfbda18ee5af45d300153b57fa5 <e1407fb7c337373dfaaae2445d828b0b9ae26a29 || >=cee137a634318bfbda18ee5af45d300153b57fa5 <57957bc7f1865778ec9b1618e15515feb6df7eb4 || >=cee137a634318bfbda18ee5af45d300153b57fa5 <546de94e41e92e1f7dc6213615fb7c794d05db98 || >=cee137a634318bfbda18ee5af45d300153b57fa5 <859380694f434597407632c29f30fdb5e763e6cc | e1407fb7c337373dfaaae2445d828b0b9ae26a29, 57957bc7f1865778ec9b1618e15515feb6df7eb4, 546de94e41e92e1f7dc6213615fb7c794d05db98, 859380694f434597407632c29f30fdb5e763e6cc |
| Linux/Linuxgeneric | 6.2 | Not reported |
Published upstream
May 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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 mlx5e_ipsec_init_macs() by replacing mlx5_query_mac_address() with ether_addr_copy() to get the local MAC address directly from netdev->dev_addr. The issue occurs because mlx5_query_mac_address() queries the hardware which involves mlx5_cmd_exec() that can sleep, but it is called from the mlx5e_ipsec_handle_event workqueue which runs in atomic context. The MAC address is already available in netdev->dev_addr, 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 schedule_timeout+0x6e/0xf0 __wait_for_common+0x91/0x1b0 cmd_exec+0xa85/0xff0 [mlx5_core] mlx5_cmd_exec+0x1f/0x50 [mlx5_core] mlx5_query_nic_vport_mac_address+0x7b/0xd0 [mlx5_core] mlx5_query_mac_address+0x19/0x30 [mlx5_core] mlx5e_ipsec_init_macs+0xc1/0x720 [mlx5_core] mlx5e_ipsec_build_accel_xfrm_attrs+0x422/0x670 [mlx5_core] mlx5e_ipsec_handle_event+0x2b9/0x460 [mlx5_core] process_one_work+0x178/0x2e0 worker_thread+0x2ea/0x430
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-43199 records a Unknown severity vulnerability in net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=cee137a634318bfbda18ee5af45d300153b57fa5 <e1407fb7c337373dfaaae2445d828b0b9ae26a29 || >=cee137a634318bfbda18ee5af45d300153b57fa5 <57957bc7f1865778ec9b1618e15515feb6df7eb4 || >=cee137a634318bfbda18ee5af45d300153b57fa5 <546de94e41e92e1f7dc6213615fb7c794d05db98 || >=cee137a634318bfbda18ee5af45d300153b57fa5 <859380694f434597407632c29f30fdb5e763e6cc | e1407fb7c337373dfaaae2445d828b0b9ae26a29, 57957bc7f1865778ec9b1618e15515feb6df7eb4, 546de94e41e92e1f7dc6213615fb7c794d05db98, 859380694f434597407632c29f30fdb5e763e6cc |
| Linux/Linuxgeneric | 6.2 | Not reported |
Published upstream
May 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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 mlx5e_ipsec_init_macs() by replacing mlx5_query_mac_address() with ether_addr_copy() to get the local MAC address directly from netdev->dev_addr. The issue occurs because mlx5_query_mac_address() queries the hardware which involves mlx5_cmd_exec() that can sleep, but it is called from the mlx5e_ipsec_handle_event workqueue which runs in atomic context. The MAC address is already available in netdev->dev_addr, 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 schedule_timeout+0x6e/0xf0 __wait_for_common+0x91/0x1b0 cmd_exec+0xa85/0xff0 [mlx5_core] mlx5_cmd_exec+0x1f/0x50 [mlx5_core] mlx5_query_nic_vport_mac_address+0x7b/0xd0 [mlx5_core] mlx5_query_mac_address+0x19/0x30 [mlx5_core] mlx5e_ipsec_init_macs+0xc1/0x720 [mlx5_core] mlx5e_ipsec_build_accel_xfrm_attrs+0x422/0x670 [mlx5_core] mlx5e_ipsec_handle_event+0x2b9/0x460 [mlx5_core] process_one_work+0x178/0x2e0 worker_thread+0x2ea/0x430
Quoted source text, attributed separately from HOL analysis.