In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix publication race for priv->channel_stats[] mlx5e_channel_stats_alloc() publishes a new entry to priv->channel_stats[] and then increments priv->stats_nch as a publication token, but neither store carries any memory barrier: priv->channel_stats[ix] = kvzalloc_node(...); if (!priv->channel_stats[ix]) return -ENOMEM; priv->stats_nch++; Concurrent readers compute the loop bound from priv->stats_nch and then dereference priv->channel_stats[i] using plain accesses, e.g. for (i = 0; i < priv->stats_nch; i++) { struct mlx5e_channel_stats *cs = priv->channel_stats[i]; ... cs->rq.packets ... } 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() -> 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 => 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.

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1793786843 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: qmi_encdec: Restrict string     length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null     terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of     bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

  - In the Linux kernel, the following vulnerability has been resolved: rv: Use strings in da monitors     tracepoints Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN:
    global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr     ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0     ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200     trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0     This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata     definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g.
    the next automaton's data in this case). The error is harmless as, while printing the string, we stop at     the null terminator, but it should still be fixed. Use the __string facilities while defining the     tracepoints to avoid reading out of bound memory. (CVE-2025-38636)

  - In the Linux kernel, the following vulnerability has been resolved: perf: arm_spe: Prevent overflow in     PERF_IDX2OFF() Cast nr_pages to unsigned long to avoid overflow when handling large AUX buffer sizes (>= 2     GiB). (CVE-2025-40081)

  - In the Linux kernel, the following vulnerability has been resolved: arch_topology: Fix incorrect error     check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in     topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic     uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to     potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation,     PTR_ERR_OR_ZERO(ptr) returns: The error code within @ptr if it is an error pointer; 0 otherwise. This     means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore     !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing     clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk)     which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().
    (CVE-2025-40346)

  - In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Add support for     Van Gogh SoC The ROG Xbox Ally (non-X) SoC features a similar architecture to the Steam Deck. While the     Steam Deck supports S3 (s2idle causes a crash), this support was dropped by the Xbox Ally which only S0ix     suspend. Since the handler is missing here, this causes the device to not suspend and the AMD GPU driver     to crash while trying to resume afterwards due to a power hang. (CVE-2025-68334)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

An update of the linux package has been released.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix publication race for
    priv->channel_stats[] mlx5e_channel_stats_alloc() publishes a new entry to priv->channel_stats[] and then
    increments priv->stats_nch as a publication token, but neither store carries any memory barrier:
    priv->channel_stats[ix] = kvzalloc_node(...); if (!priv->channel_stats[ix]) return -ENOMEM;
    priv->stats_nch++; Concurrent readers compute the loop bound from priv->stats_nch and then dereference
    priv->channel_stats[i] using plain accesses, e.g. for (i = 0; i < priv->stats_nch; i++) { struct
    mlx5e_channel_stats *cs = priv->channel_stats[i]; ... cs->rq.packets ... } 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() -> 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 => 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. (CVE-2026-72341)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - net/mlx5e: Fix publication race for priv->channel_stats[] mlx5e_channel_stats_alloc() publishes a new     entry to priv->channel_stats[] and then increments priv->stats_nch as a publication token, but neither     store carries any memory barrier: priv->channel_stats[ix] = kvzalloc_node(...); if     (!priv->channel_stats[ix]) return -ENOMEM; priv->stats_nch++; Concurrent readers compute the loop bound     from priv->stats_nch and then dereference priv->channel_stats[i] using plain accesses, e.g. for (i = 0; i     < priv->stats_nch; i++) { struct mlx5e_channel_stats *cs = priv->channel_stats[i]; ... cs->rq.packets ...
    } 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() -> 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 => 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. (CVE-2026-72341)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
377900	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3402)	Nessus	Amazon Linux Local Security Checks	Local	high
377578	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel (NVIDIA) vulnerabilities (USN-9003-1)	Nessus	Ubuntu Local Security Checks	Local	medium
376201	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1793786843)	Nessus	Alma Linux Local Security Checks	Local	high
375106	Photon OS 5.0: Linux PHSA-2026-5.0-92-1008	Nessus	PhotonOS Local Security Checks	Local	critical
375020	Photon OS 5.0: Linux PHSA-2026-5.0-91-1008	Nessus	PhotonOS Local Security Checks	Local	critical
365768	Ubuntu 26.04 LTS : Linux kernel (Azure) vulnerabilities (USN-8888-1)	Nessus	Ubuntu Local Security Checks	Local	medium
365767	Ubuntu 26.04 LTS : Linux kernel vulnerabilities (USN-8887-1)	Nessus	Ubuntu Local Security Checks	Local	medium
365463	Ubuntu 26.04 LTS : Linux kernel (OEM) vulnerabilities (USN-8889-1)	Nessus	Ubuntu Local Security Checks	Local	medium
469911	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.21	Tenable Cloud Security	Google COS Security Checks	Local	medium
469911	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.21	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	medium
350138	openSUSE 16: cluster-md-kmp-64kb / cluster-md-kmp-azure / cluster-md-kmp-default / etc (openSUSE-SU-2026:21910-1)	Nessus	SuSE Local Security Checks	Local	high
347900	SUSE SLED15 / SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:4254-1)	Nessus	SuSE Local Security Checks	Local	high
341880	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-2071)	Nessus	Amazon Linux Local Security Checks	Local	high
335707	Linux Distros Unpatched Vulnerability : CVE-2026-72341	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-72341

medium

Tenable Plugins

high

medium

high

critical

critical

medium

medium

medium

medium

medium

high

high

high

medium