{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.180-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.100-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.5-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003estats_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-\u003estats_agent.buf set to ZERO_SIZE_PTR.  Once channels are opened (priv-\u003estats_nch \u003e 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-\u003emax_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-\u003erings = 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-\u003estats_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-\u003estats_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-\u003echannel_stats) and lazily populating entries up to stats_nch on demand.",
  "id": "DEBIAN-CVE-2026-72343",
  "modified": "2026-09-14T16:47:48.862292836Z",
  "published": "2026-08-15T06:22:07.650Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-72343"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-72343"
  ]
}