In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1792762308 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w     reset and tm thread for reply queue When the task management thread processes reply queues while the reset     thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset     thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize     access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to     block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits     up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as     unrecoverable. (CVE-2025-37861)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send     timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if     the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT     timers. Should fix the BUG: sporadically seen by BlueZ test bot (in Mesh - Send cancel - 1 test). Log:
    ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:
    kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60
    __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0     vhci_release+0x18b/0x240 ------ (CVE-2025-40284)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Disable periods-     elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream     while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two     operations shall be synchronized to avoid slab-use-after-free or worse errors. (CVE-2025-40344)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in     ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an     outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and     passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm.
    The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an     attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside     icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This     would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a     fake TLV without checking if the remaining packet length can hold the full 18-byte struct     ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the     packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and     ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err()     needs to be changed. A separate patch would be better anyway. (CVE-2026-43038)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in     rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before     copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to     free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init()     (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second     rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this:
    kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe]     rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150     [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. (CVE-2026-45852)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w     reset and tm thread for reply queue When the task management thread processes reply queues while the reset     thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset     thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize     access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to     block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits     up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as     unrecoverable. (CVE-2025-37861)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send     timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if     the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT     timers. Should fix the BUG: sporadically seen by BlueZ test bot (in Mesh - Send cancel - 1 test). Log:
    ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:
    kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60
    __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0     vhci_release+0x18b/0x240 ------ (CVE-2025-40284)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Disable periods-     elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream     while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two     operations shall be synchronized to avoid slab-use-after-free or worse errors. (CVE-2025-40344)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in     ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an     outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and     passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm.
    The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an     attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside     icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This     would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a     fake TLV without checking if the remaining packet length can hold the full 18-byte struct     ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the     packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and     ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err()     needs to be changed. A separate patch would be better anyway. (CVE-2026-43038)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in     rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before     copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to     free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init()     (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second     rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this:
    kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe]     rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150     [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. (CVE-2026-45852)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: vhost: fix hung thread due to     erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and     last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with     iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends     up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous     entry. Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340     vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0     drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0     kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Reported by syzbot at:
    https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87 To fix this, do two things: 1. Return -EINVAL     in vhost_chr_write_iter() when userspace asks to map a range with size 0. 2. Fix     vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries.
    (CVE-2022-48862)

  - In the Linux kernel, the following vulnerability has been resolved: net: hns3: add vlan list lock to     protect vlan list When adding port base VLAN, vf VLAN need to remove from HW and modify the vlan state in     vf VLAN list as false. If the periodicity task is freeing the same node, it may cause use after free     error. This patch adds a vlan list lock to protect the vlan list. (CVE-2022-49182)

  - In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: Fix crash due to race     between amd_pmu_enable_all, perf NMI and throttling amd_pmu_enable_all() does: if (!test_bit(idx,     cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can     come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the     one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled     event has very low sampling period and causes immediate successive NMI, causing the event to be throttled,     cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in     amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the     NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF:
    supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK>     amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ?     hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60
    __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0     cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK>     amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of     BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and     enable it back while returning from NMI. This will solve the issue by not enabling those events whose     active_masks are set but are not yet enabled in hw pmu. (CVE-2022-49781)

  - In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix memory leak on     add_disk() failures When a gendisk is successfully initialized but add_disk() fails such as when a loop     device has invalid number of minor device numbers specified, blkcg_init_disk() is called during init and     then blkcg_exit_disk() during error handling. Unfortunately, iolatency gets initialized in the former but     doesn't get cleaned up in the latter. This is because, in non-error cases, the cleanup is performed by     del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos policies, iolatency being one of     them, can only be activated once the disk is fully registered and visible. That assumption is true for wbt     and iocost, but not so for iolatency as it gets initialized before add_disk() is called. It is desirable     to lazy-init rq_qos policies because they are optional features and add to hot path overhead once     initialized - each IO has to walk all the registered rq_qos policies. So, we want to switch iolatency to     lazy init too. However, that's a bigger change. As a fix for the immediate problem, let's just add an     extra call to rq_qos_exit() in blkcg_exit_disk(). This is safe because duplicate calls to rq_qos_exit()     become noop's. (CVE-2022-50550)

  - In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to     remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put     down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed.
    Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1)     Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host     ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up     [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23:
    enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen     1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd     ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0     down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc     mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off     (CVE-2024-26830)

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

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

  - nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify     command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-     backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed     namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The     I/O command set is selected by the host-supplied CSI field and the command is routed here whenever     CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace     is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.
    (CVE-2026-90228)

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

ID	Name	Product	Family	Type	Severity
371428	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792762308)	Nessus	Rocky Linux Local Security Checks	Local	high
371426	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792762308)	Nessus	Alma Linux Local Security Checks	Local	high
366919	Debian dla-4841 : ata-modules-6.1.0-53-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
366742	SUSE SLED15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:4706-1)	Nessus	SuSE Local Security Checks	Local	high
364688	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1791741836)	Nessus	Alma Linux Local Security Checks	Local	critical
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
347399	Linux Distros Unpatched Vulnerability : CVE-2026-90228	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-90228

high

Tenable Plugins

high

high

high

high

critical

high

high

high

high