CVE-2026-72343

Status: UPDATED  |  Advisory ID: CVE-2026-72343

Key Details

Affected Products, Subsystems & Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation

mlx5e_hv_vhca_stats_create() is called from mlx5e_nic_enable(),

before mlx5e_open(). At that point priv->stats_nch is still zero,

because it is only ever incremented in mlx5e_channel_stats_alloc(),

which is reached only from mlx5e_open_channel().

mlx5e_hv_vhca_stats_buf_size() therefore returns 0, and

kvzalloc(0, GFP_KERNEL) returns ZERO_SIZE_PTR ((void *)16) rather

than NULL. The "if (!buf)" guard does not catch this, and

mlx5e_hv_vhca_stats_create() completes "successfully" with

priv->stats_agent.buf set to ZERO_SIZE_PTR.

Once channels are opened (priv->stats_nch > 0) and the hypervisor

enables stats reporting, mlx5e_hv_vhca_stats_work() recomputes

buf_len using the new non-zero stats_nch and calls

memset(buf, 0, buf_len) on ZERO_SIZE_PTR, faulting at address 0x10.

Allocate the buffer based on priv->max_nch, which is set in

mlx5e_priv_init() and is the upper bound on stats_nch:

- Add a separate helper mlx5e_hv_vhca_stats_buf_max_size() that

returns sizeof(per_ring_stats) * max(max_nch, stats_nch), and

use it for the kvzalloc() in mlx5e_hv_vhca_stats_create().

- Keep mlx5e_hv_vhca_stats_buf_size() (which returns based on

stats_nch) for the worker's active payload size, so the wire

format (block->rings = stats_nch) and the amount of data filled

by mlx5e_hv_vhca_fill_stats() are unchanged.

The max(max_nch, stats_nch) guard handles the rare case where

mlx5e_attach_netdev() recomputes max_nch downward across a

detach/resume cycle while priv->stats_nch persists (mlx5e_detach_netdev

does not call mlx5e_priv_cleanup, so stats_nch is only reset when

the netdev is destroyed). Without the guard, the worker could compute

buf_len from stats_nch and overrun the smaller buffer allocated based

on the reduced max_nch.

Allocating a non-zero buffer also makes the kvzalloc() failure path in

mlx5e_hv_vhca_stats_create() reachable for the first time: it returns

early without (re)creating the agent. Clear

priv->stats_agent.{agent,buf} in mlx5e_hv_vhca_stats_destroy() after

freeing them, so that if a later create() bails out on this path, a

subsequent teardown does not double-free the stale agent/buffer left

from a previous enable/disable cycle.

This mirrors the existing mlx5e pattern of preallocating arrays of

size max_nch (e.g. priv->channel_stats) and lazily populating

entries up to stats_nch on demand. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References