{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "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 publication race for priv-\u003echannel_stats[]  mlx5e_channel_stats_alloc() publishes a new entry to priv-\u003echannel_stats[] and then increments priv-\u003estats_nch as a publication token, but neither store carries any memory barrier:  \tpriv-\u003echannel_stats[ix] = kvzalloc_node(...); \tif (!priv-\u003echannel_stats[ix]) \t\treturn -ENOMEM; \tpriv-\u003estats_nch++;  Concurrent readers compute the loop bound from priv-\u003estats_nch and then dereference priv-\u003echannel_stats[i] using plain accesses, e.g.  \tfor (i = 0; i \u003c priv-\u003estats_nch; i++) { \t\tstruct mlx5e_channel_stats *cs = priv-\u003echannel_stats[i]; \t\t... cs-\u003erq.packets ... \t}  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() -\u003e 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  =\u003e  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.",
  "id": "DEBIAN-CVE-2026-72341",
  "modified": "2026-09-14T16:47:45.554393485Z",
  "published": "2026-08-15T06:22:07.403Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-72341"
    }
  ],
  "upstream": [
    "CVE-2026-72341"
  ]
}