Answer in brief
CVE-2026-72341 records a Unknown severity vulnerability in net/mlx5e: Fix publication race for priv->channel_stats[]. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), 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), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <5c7e3755abf663f033de24f917b77685e9543045 || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <815515ec68f527ca755cb1e2c1ff9148f6b3ea56 || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <5a799714e8ca0bce9ea40694f49914cf1adbbaa9 | 5c7e3755abf663f033de24f917b77685e9543045, 815515ec68f527ca755cb1e2c1ff9148f6b3ea56, 5a799714e8ca0bce9ea40694f49914cf1adbbaa9 |
| Linux/Linuxgeneric | 5.17 | Not reported |
| Linux/Linuxgeneric | >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <268869794170af37727816ad02051808adb9c9c3 || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <acd34d24342a28794e706ce8191ca6c3114a38ae || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <5c7e3755abf663f033de24f917b77685e9543045 || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <815515ec68f527ca755cb1e2c1ff9148f6b3ea56 || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <5a799714e8ca0bce9ea40694f49914cf1adbbaa9 | 268869794170af37727816ad02051808adb9c9c3, acd34d24342a28794e706ce8191ca6c3114a38ae, 5c7e3755abf663f033de24f917b77685e9543045, 815515ec68f527ca755cb1e2c1ff9148f6b3ea56, 5a799714e8ca0bce9ea40694f49914cf1adbbaa9 |
| Linux/Linuxgeneric | >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <df122c593735aa5e1c97457767aa10ed8fa972e0 || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <268869794170af37727816ad02051808adb9c9c3 || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <acd34d24342a28794e706ce8191ca6c3114a38ae || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <5c7e3755abf663f033de24f917b77685e9543045 || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <815515ec68f527ca755cb1e2c1ff9148f6b3ea56 || >=fa691d0c9c0812b9045f3a9420862e47b3b92518 <5a799714e8ca0bce9ea40694f49914cf1adbbaa9 | df122c593735aa5e1c97457767aa10ed8fa972e0, 268869794170af37727816ad02051808adb9c9c3, acd34d24342a28794e706ce8191ca6c3114a38ae, 5c7e3755abf663f033de24f917b77685e9543045, 815515ec68f527ca755cb1e2c1ff9148f6b3ea56, 5a799714e8ca0bce9ea40694f49914cf1adbbaa9 |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 30, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix publication race for priv->channel_stats[] mlx5e_channel_stats_alloc() publishes a new entry to priv->channel_stats[] and then increments priv->stats_nch as a publication token, but neither store carries any memory barrier: priv->channel_stats[ix] = kvzalloc_node(...); if (!priv->channel_stats[ix]) return -ENOMEM; priv->stats_nch++; Concurrent readers compute the loop bound from priv->stats_nch and then dereference priv->channel_stats[i] using plain accesses, e.g. for (i = 0; i < priv->stats_nch; i++) { struct mlx5e_channel_stats *cs = priv->channel_stats[i]; ... cs->rq.packets ... } On weakly-ordered architectures (ARM, PowerPC, RISC-V) the writes to channel_stats[ix] and stats_nch may become visible to other CPUs out of program order. A reader can observe stats_nch == N while still seeing channel_stats[N-1] == NULL, leading to a NULL pointer dereference in the channel_stats loop. This has been observed in production on BlueField-3 DPUs (arm64), where ovs-vswitchd queries netdev statistics over netlink during NIC bringup, racing mlx5e_open_channel() -> mlx5e_channel_stats_alloc() on another CPU: Unable to handle kernel NULL pointer dereference at virtual address 0x840 Hardware name: BlueField-3 DPU pc : mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core] Call trace: mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core] dev_get_stats+0x50/0xc0 ovs_vport_get_stats+0x38/0xac [openvswitch] ovs_vport_cmd_fill_info+0x194/0x290 [openvswitch] ovs_vport_cmd_get+0xbc/0x10c [openvswitch] genl_family_rcv_msg_doit+0xd0/0x160 genl_rcv_msg+0xec/0x1f0 netlink_rcv_skb+0x64/0x130 genl_rcv+0x40/0x60 netlink_unicast+0x2fc/0x370 netlink_sendmsg+0x1dc/0x454 ... __arm64_sys_sendmsg+0x2c/0x40 Add mlx5e_stats_nch_write() and mlx5e_stats_nch_read() helpers in en.h that wrap the smp_store_release()/smp_load_acquire() pair on stats_nch. The release/acquire pair establishes the contract: stats_nch == N => channel_stats[0..N-1] are visible and non-NULL. Publish the stats_nch increment via mlx5e_stats_nch_write() in the writer (mlx5e_channel_stats_alloc()), and read stats_nch via mlx5e_stats_nch_read() in all readers: mlx5e RX/TX queue stats, mlx5e_get_base_stats(), ethtool channels stats, IPoIB stats, the sw_stats fold and the HV VHCA stats agent.
Quoted source text, attributed separately from HOL analysis.