In the Linux kernel, the following vulnerability has been resolved: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() During futex_key_to_node_opt() execution, vma->vm_policy is read under speculative mmap lock and RCU. Concurrently, mbind() may call vma_replace_policy() which frees the old mempolicy immediately via kmem_cache_free(). This creates a race where __futex_key_to_node() dereferences a freed mempolicy pointer, causing a use-after-free read of mpol->mode. [ 151.412631] BUG: KASAN: slab-use-after-free in __futex_key_to_node (kernel/futex/core.c:349) [ 151.414046] Read of size 2 at addr ffff888001c49634 by task e/87 [ 151.415969] Call Trace: [ 151.416732] __asan_load2 (mm/kasan/generic.c:271) [ 151.416777] __futex_key_to_node (kernel/futex/core.c:349) [ 151.416822] get_futex_key (kernel/futex/core.c:374 kernel/futex/core.c:386 kernel/futex/core.c:593) Fix by adding rcu to __mpol_put().

The remote RockyLinux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RLSA-2026:51035 advisory.

    * kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() (CVE-2026-23415)

    * kernel: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() (CVE-2026-43450)

    Bug Fix(es) and Enhancement(s):

    * kernel panics caused by NULL pointer dereferences within octeon_ep_vf [rhel-9.8.z] (JIRA:Rocky     Linux-186331)

    * [Rocky Linux 9.4] Kernel memory reclaim bug  [rhel-9.8.z] (JIRA:Rocky Linux-211058)

    * Bond network interface is not coming up with MTU 9000 while vPMEM is enabled [rhel-9.8.z] (JIRA:Rocky     Linux-215575)

Tenable has extracted the preceding description block directly from the RockyLinux security advisory.

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

The remote Oracle Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-51035 advisory.

    - futex: Prevent lockup in requeue-PI during signal/ timeout wakeup (Waiman Long) [RHEL-193526]     {CVE-2026-52977}
    - futex: Require sys_futex_requeue() to have identical flags (Waiman Long) [RHEL-193526] {CVE-2026-31554}
    - futex: Clear stale exiting pointer in futex_lock_pi() retry path (Waiman Long) [RHEL-193526]     {CVE-2026-31555}
    - futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() (Waiman Long) [RHEL-193526]     {CVE-2026-23415}

Tenable has extracted the preceding description block directly from the Oracle Linux security advisory.

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

The remote Redhat Enterprise Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2026:51035 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() (CVE-2026-23415)

    * kernel: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() (CVE-2026-43450)

    Bug Fix(es) and Enhancement(s):

    * kernel panics caused by NULL pointer dereferences within octeon_ep_vf [rhel-9.8.z] (JIRA:RHEL-186331)

    * [RHEL 9.4] Kernel memory reclaim bug  [rhel-9.8.z] (JIRA:RHEL-211058)

    * Bond network interface is not coming up with MTU 9000 while vPMEM is enabled [rhel-9.8.z]     (JIRA:RHEL-215575)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

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

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-725.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: futex: Fix UaF between     futex_key_to_node_opt() and vma_replace_policy() During futex_key_to_node_opt() execution, vma->vm_policy     is read under speculative mmap lock and RCU. Concurrently, mbind() may call vma_replace_policy() which     frees the old mempolicy immediately via kmem_cache_free(). This creates a race where __futex_key_to_node()     dereferences a freed mempolicy pointer, causing a use-after-free read of mpol->mode. [ 151.412631] BUG:
    KASAN: slab-use-after-free in __futex_key_to_node (kernel/futex/core.c:349) [ 151.414046] Read of size 2     at addr ffff888001c49634 by task e/87 [ 151.415969] Call Trace: [ 151.416732] __asan_load2     (mm/kasan/generic.c:271) [ 151.416777] __futex_key_to_node (kernel/futex/core.c:349) [ 151.416822]     get_futex_key (kernel/futex/core.c:374 kernel/futex/core.c:386 kernel/futex/core.c:593) Fix by adding rcu     to __mpol_put(). (CVE-2026-23415)

  - In the Linux kernel, the following vulnerability has been resolved: futex: Require sys_futex_requeue() to     have identical flags Nicholas reported that his LLM found it was possible to create a UaF when     sys_futex_requeue() is used with different flags. The initial motivation for allowing different flags was     the variable sized futex, but since that hasn't been merged (yet), simply mandate the flags are identical,     as is the case for the old style sys_futex() requeue operations. (CVE-2026-31554)

  - In the Linux kernel, the following vulnerability has been resolved: futex: Clear stale exiting pointer in     futex_lock_pi() retry path Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at     wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner     is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After     wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry,     if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to     wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit()     futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic()     attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY     wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner     goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever //     value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting) Fix     this by resetting upon retry, essentially aligning it with requeue_pi. (CVE-2026-31555)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix IRQ cleanup on 6xxx     probe failure When adf_dev_up() partially completes and then fails, the IRQ handlers registered during     adf_isr_resource_alloc() are not detached before the MSI-X vectors are released. Since the device is     enabled with pcim_enable_device(), calling pci_alloc_irq_vectors() internally registers pcim_msi_release()     as a devres action. On probe failure, devres runs pcim_msi_release() which calls pci_free_irq_vectors(),     tearing down the MSI-X vectors while IRQ handlers (for example 'qat0-bundle0') are still attached. This     causes remove_proc_entry() warnings: [ 22.163964] remove_proc_entry: removing non-empty directory     'irq/143', leaking at least 'qat0-bundle0' Moving the devm_add_action_or_reset() before adf_dev_up() does     not solve the problem since devres runs in LIFO order and pcim_msi_release(), registered later inside     adf_dev_up(), would still fire before adf_device_down(). Fix by calling adf_dev_down() explicitly when     adf_dev_up() fails, to properly free IRQ handlers before devres releases the MSI-X vectors.
    (CVE-2026-46060)

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.

  - futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() During futex_key_to_node_opt()     execution, vma->vm_policy is read under speculative mmap lock and RCU. Concurrently, mbind() may call     vma_replace_policy() which frees the old mempolicy immediately via kmem_cache_free(). This creates a race     where __futex_key_to_node() dereferences a freed mempolicy pointer, causing a use-after-free read of     mpol->mode. [ 151.412631] BUG: KASAN: slab-use-after-free in __futex_key_to_node (kernel/futex/core.c:349)     [ 151.414046] Read of size 2 at addr ffff888001c49634 by task e/87 [ 151.415969] Call Trace: [ 151.416732]
    __asan_load2 (mm/kasan/generic.c:271) [ 151.416777] __futex_key_to_node (kernel/futex/core.c:349) [     151.416822] get_futex_key (kernel/futex/core.c:374 kernel/futex/core.c:386 kernel/futex/core.c:593) Fix by     adding rcu to __mpol_put(). (CVE-2026-23415)

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

ID	Name	Product	Family	Severity
333372	RockyLinux 9 : kernel (RLSA-2026:51035)	Nessus	Rocky Linux Local Security Checks	high
333327	Oracle Linux 9 : kernel (ELSA-2026-51035)	Nessus	Oracle Linux Local Security Checks	high
333113	RHEL 9 : kernel (RHSA-2026:51035)	Nessus	Red Hat Local Security Checks	high
328036	CentOS 9 : kernel-5.14.0-725.el9	Nessus	CentOS Local Security Checks	high
316948	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-1746)	Nessus	Amazon Linux Local Security Checks	high
304783	Linux Distros Unpatched Vulnerability : CVE-2026-23415	Nessus	Misc.	high

Detections

Analytics

CVE-2026-23415

high

Tenable Plugins

high

high

high

high

high

high