CVE-2026-72342: net/mlx5e: Fix HV VHCA stats agent registration race
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix HV VHCA stats agent registration race
mlx5ehvvhcastatscreate() registers the stats agent through mlx5hvvhcaagentcreate(). The helper publishes the agent in hvvhca->agents[type] under agentslock and immediately schedules an asynchronous control invalidation on the HV VHCA workqueue before returning to mlx5e.
The asynchronous invalidation invokes the control agent's invalidate callback, which reads the hypervisor control block and forwards the command to mlx5ehvvhcastatscontrol(). That callback may either:
- call canceldelayedworksync(&priv->statsagent.work), or - call queuedelayedwork(priv->wq, &sagent->work, sagent->delay).
However, the delayedwork and priv->statsagent.agent are only initialized after mlx5hvvhcaagentcreate() returns to mlx5e:
agent = mlx5hvvhcaagentcreate(...); / publish + invalidate / ... priv->statsagent.agent = agent; / too late / INITDELAYEDWORK(&priv->statsagent.work, ...); / too late /
If the asynchronous control path runs before the two assignments above, it can:
- Operate on an uninitialized delayedwork whose timer.function is NULL. queuedelayedwork() calls addtimer() unconditionally, so when the timer expires the timer softirq invokes a NULL function pointer. - Re-initialize the timer later through INITDELAYEDWORK() while the timer is already enqueued in the timer wheel, corrupting the hlist (entry.pprev cleared while the previous bucket node still points at this entry). - When the worker eventually runs, mlx5ehvvhcastatswork() reads sagent->agent (NULL) and dereferences it inside mlx5hvvhcaagentwrite().
Fix this by:
- Initializing priv->statsagent.work before invoking mlx5hvvhcaagentcreate(), so the work is always in a valid state when the control callback observes it. - Adding a struct mlx5hvvhcaagent ctxupdate out-parameter to mlx5hvvhcaagentcreate(). The helper writes the agent pointer to ctxupdate before publishing into hvvhca->agents[] and triggering the agentsupdate flow, so any callback subsequently invoked from that flow already sees a valid priv->statsagent.agent. This avoids having the control callback participate in agent initialization.
While at it, access priv->statsagent.agent with READONCE()/WRITEONCE() for the cross-CPU access with the worker, and clear priv->statsagent.buf on the agentcreate() failure path.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure delayed_work is initialized at the correct time so the async control path cannot queue a delayed_work instance whose timer.function or priv->stats_agent.agent are still uninitialized (avoid "INIT_DELAYED_WORK(&priv->stats_agent.work, ...); /* too late */").
Linux kernel (mlx5e HV VHCA stats agent) priv->stats_agent.work initialization order = Initialize priv->stats_agent.work before registering/publishing the agent and before any asynchronous control/invalidation can enqueue the delayed work - Configuration
Prevent the worker/control callback race by ensuring cross-CPU access to priv->stats_agent.agent is synchronized (per material: use READ_ONCE()/WRITE_ONCE()) so callbacks do not dereference agent=NULL during asynchronous invalidation and agent_update flow.
Linux kernel (mlx5e HV VHCA stats agent) priv->stats_agent.agent publication/invalidation synchronization = Use READ_ONCE()/WRITE_ONCE() for cross-CPU access and publish agent only after initialization to prevent callbacks from observing NULL/uninitialized agent - Compensating control
If the delayed work may have been queued before initialization completes, cancel it before dereferencing agent/state: call cancel_delayed_work_sync(&priv->stats_agent.work) or ensure queue_delayed_work(priv->wq, &sagent->work, sagent->delay) only happens after init (both appear as the relevant unsafe operations/mitigation in the material).
- Operational
After applying the fix, ensure the HV VHCA stats agent creation/update path no longer publishes an agent late and that the delayed work callback (mlx5e_hv_vhca_stats_work) cannot run with timer.function or priv->stats_agent.agent still NULL/uninitialized (verify by exercising the asynchronous control invalidation path).