CVE-2026-72341: net/mlx5e: Fix publication race for priv->channel_stats[]
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix publication race for priv->channelstats[]
mlx5echannelstatsalloc() publishes a new entry to priv->channelstats[] and then increments priv->statsnch as a publication token, but neither store carries any memory barrier:
priv->channelstats[ix] = kvzallocnode(...); if (!priv->channelstats[ix]) return -ENOMEM; priv->statsnch++;
Concurrent readers compute the loop bound from priv->statsnch and then dereference priv->channelstats[i] using plain accesses, e.g.
for (i = 0; i < priv->statsnch; i++) { struct mlx5echannelstats cs = priv->channelstats[i]; ... cs->rq.packets ... }
On weakly-ordered architectures (ARM, PowerPC, RISC-V) the writes to channelstats[ix] and statsnch may become visible to other CPUs out of program order. A reader can observe statsnch == N while still seeing channelstats[N-1] == NULL, leading to a NULL pointer dereference in the channelstats loop.
This has been observed in production on BlueField-3 DPUs (arm64), where ovs-vswitchd queries netdev statistics over netlink during NIC bringup, racing mlx5eopenchannel() -> mlx5echannelstatsalloc() on another CPU:
Unable to handle kernel NULL pointer dereference at virtual address 0x840 Hardware name: BlueField-3 DPU pc : mlx5efoldswstats64+0x30/0x180 [mlx5core] Call trace: mlx5efoldswstats64+0x30/0x180 [mlx5core] devgetstats+0x50/0xc0 ovsvportgetstats+0x38/0xac [openvswitch] ovsvportcmdfillinfo+0x194/0x290 [openvswitch] ovsvportcmdget+0xbc/0x10c [openvswitch] genlfamilyrcvmsgdoit+0xd0/0x160 genlrcvmsg+0xec/0x1f0 netlinkrcvskb+0x64/0x130 genlrcv+0x40/0x60 netlinkunicast+0x2fc/0x370 netlinksendmsg+0x1dc/0x454 ... arm64syssendmsg+0x2c/0x40
Add mlx5estatsnchwrite() and mlx5estatsnchread() helpers in en.h that wrap the smpstorerelease()/smploadacquire() pair on statsnch. The release/acquire pair establishes the contract:
statsnch == N => channelstats[0..N-1] are visible and non-NULL.
Publish the statsnch increment via mlx5estatsnchwrite() in the writer (mlx5echannelstatsalloc()), and read statsnch via mlx5estatsnchread() in all readers: mlx5e RX/TX queue stats, mlx5egetbasestats(), ethtool channels stats, IPoIB stats, the swstats fold and the HV VHCA stats agent.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (net/mlx5e)to a version that resolves this vulnerability.Patch net/mlx5e: Fix publication race for priv->channel_stats[] - Configuration
Apply the publication race fix so that mlx5e_channel_stats_alloc() publishes channel_stats[] with proper ordering, and readers use mlx5e_stats_nch_read() to load priv->stats_nch with acquire semantics (paired with mlx5e_stats_nch_write() using release semantics), ensuring readers cannot compute a loop bound from priv->stats_nch before channel_stats[] stores are visible.
mlx5e (net/mlx5e) Use smp_store_release()/smp_load_acquire() publication pattern for priv->stats_nch and publish channel_stats with helpers = Use mlx5e_stats_nch_write() and mlx5e_stats_nch_read() helpers with release/acquire instead of plain publication/increment