In the Linux kernel, the following vulnerability has been resolved: nfsd: fix fcache_disposal UAF by inlining dispose state into nfsd_net nfsd_file_dispose_list_delayed() defers fput() to nfsd service threads via a per-net freeme queue, preventing the shrinker and GC worker from bearing the cost of closing files (see ffb402596147). However, the queue lives in a separately-allocated struct nfsd_fcache_disposal that is freed by nfsd_free_fcache_disposal_net() during per-net teardown. The global shrinker, laundrette, and fsnotify callbacks can still be inside nfsd_file_dispose_list_delayed() dereferencing that pointer, causing a use-after-free. Inline the spinlock and freeme list directly into struct nfsd_net (as fcache_dispose_lock and fcache_dispose_list), eliminating the separately allocated struct nfsd_fcache_disposal entirely. These fields now have the same lifetime as the net namespace itself, so there is no dangling pointer to chase. nfsd_file_cache_start_net() now just initializes the inline fields and cannot fail due to allocation. nfsd_file_cache_shutdown_net() drains the inline list directly instead of freeing a separate struct. The alloc/free helpers are removed.

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: nfsd: fix fcache_disposal UAF by
    inlining dispose state into nfsd_net nfsd_file_dispose_list_delayed() defers fput() to nfsd service
    threads via a per-net freeme queue, preventing the shrinker and GC worker from bearing the cost of closing
    files (see ffb402596147). However, the queue lives in a separately-allocated struct nfsd_fcache_disposal
    that is freed by nfsd_free_fcache_disposal_net() during per-net teardown. The global shrinker, laundrette,
    and fsnotify callbacks can still be inside nfsd_file_dispose_list_delayed() dereferencing that pointer,
    causing a use-after-free. Inline the spinlock and freeme list directly into struct nfsd_net (as
    fcache_dispose_lock and fcache_dispose_list), eliminating the separately allocated struct
    nfsd_fcache_disposal entirely. These fields now have the same lifetime as the net namespace itself, so
    there is no dangling pointer to chase. nfsd_file_cache_start_net() now just initializes the inline fields
    and cannot fail due to allocation. nfsd_file_cache_shutdown_net() drains the inline list directly instead
    of freeing a separate struct. The alloc/free helpers are removed. (CVE-2026-89682)

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

  - In the Linux kernel, the following vulnerability has been resolved: kunit: Fix potential null dereference     in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL     check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

  - In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: fix partial SETREGSET     for NT_ARM_FPMR Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable, and a SETREGSET     call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written     back to target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from the kernel stack. The     read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix     this by initializing the temporary value before copying the regset from userspace, as for other regsets     (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing     contents of FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write     NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | |     Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr =     0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr =     0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr |     GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to     write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     (CVE-2024-57878)

  - In the Linux kernel, the following vulnerability has been resolved: mptcp: fix 'scheduling while atomic'     in mptcp_pm_nl_append_new_local_addr If multiple connection requests attempt to create an implicit mptcp     endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none     found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id. In this case, the     concurrent new_local_addr calls may delete the address entry created by the previous caller. These deletes     use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called.
    During packet recv, the caller may be in a rcu read critical section and have preemption disabled. An     example stack: BUG: scheduling while atomic: swapper/2/0/0x00000302 Call Trace: <IRQ> dump_stack_lvl     (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug     (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33     kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207     kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84     kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160)     wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116     kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311     kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr     (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id     (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req     (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305)     tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651)     tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv     (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))     ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver     (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)     ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv     (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core     (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685     net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449     include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
    __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs     (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)     irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ>     This problem seems particularly prevalent if the user advertises an endpoint that has a different external     vs internal address. In the case where the external address is advertised and multiple connections already     exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the     first local_addr_list entries which have the internal address instead. Fix by skipping the replacement of     an existing implicit local address if called via mptcp_pm_nl_get_local_id. (CVE-2025-21938)

  - In the Linux kernel, the following vulnerability has been resolved: devlink: fix xa_alloc_cyclic() error     handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will     cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking     if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
    (CVE-2025-22017)

  - In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path     of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence     and then return. The code is waiting on m->fence which could be the local fence but this is only stable     under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit     762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

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 Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1791800936 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: kunit: Fix potential null dereference     in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL     check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

  - In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: fix partial SETREGSET     for NT_ARM_FPMR Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable, and a SETREGSET     call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written     back to target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from the kernel stack. The     read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix     this by initializing the temporary value before copying the regset from userspace, as for other regsets     (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing     contents of FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write     NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | |     Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr =     0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr =     0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr |     GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to     write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     (CVE-2024-57878)

  - In the Linux kernel, the following vulnerability has been resolved: mptcp: fix 'scheduling while atomic'     in mptcp_pm_nl_append_new_local_addr If multiple connection requests attempt to create an implicit mptcp     endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none     found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id. In this case, the     concurrent new_local_addr calls may delete the address entry created by the previous caller. These deletes     use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called.
    During packet recv, the caller may be in a rcu read critical section and have preemption disabled. An     example stack: BUG: scheduling while atomic: swapper/2/0/0x00000302 Call Trace: <IRQ> dump_stack_lvl     (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug     (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33     kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207     kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84     kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160)     wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116     kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311     kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr     (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id     (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req     (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305)     tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651)     tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv     (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))     ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver     (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)     ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv     (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core     (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685     net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449     include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
    __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs     (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)     irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ>     This problem seems particularly prevalent if the user advertises an endpoint that has a different external     vs internal address. In the case where the external address is advertised and multiple connections already     exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the     first local_addr_list entries which have the internal address instead. Fix by skipping the replacement of     an existing implicit local address if called via mptcp_pm_nl_get_local_id. (CVE-2025-21938)

  - In the Linux kernel, the following vulnerability has been resolved: devlink: fix xa_alloc_cyclic() error     handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will     cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking     if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
    (CVE-2025-22017)

  - In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path     of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence     and then return. The code is waiting on m->fence which could be the local fence but this is only stable     under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit     762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

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.

  - nfsd: fix fcache_disposal UAF by inlining dispose state into nfsd_net nfsd_file_dispose_list_delayed()     defers fput() to nfsd service threads via a per-net freeme queue, preventing the shrinker and GC worker     from bearing the cost of closing files (see ffb402596147). However, the queue lives in a separately-     allocated struct nfsd_fcache_disposal that is freed by nfsd_free_fcache_disposal_net() during per-net     teardown. The global shrinker, laundrette, and fsnotify callbacks can still be inside     nfsd_file_dispose_list_delayed() dereferencing that pointer, causing a use-after-free. Inline the spinlock     and freeme list directly into struct nfsd_net (as fcache_dispose_lock and fcache_dispose_list),     eliminating the separately allocated struct nfsd_fcache_disposal entirely. These fields now have the same     lifetime as the net namespace itself, so there is no dangling pointer to chase.
    nfsd_file_cache_start_net() now just initializes the inline fields and cannot fail due to allocation.
    nfsd_file_cache_shutdown_net() drains the inline list directly instead of freeing a separate struct. The     alloc/free helpers are removed. (CVE-2026-89682)

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

ID	Name	Product	Family	Type	Severity
475789	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 20162.0.0	Tenable Cloud Security	Google COS Security Checks	Local	high
475789	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 20162.0.0	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	high
475298	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.106	Tenable Cloud Security	Google COS Security Checks	Local	high
475298	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.106	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	high
365283	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3187)	Nessus	Amazon Linux Local Security Checks	Local	medium
364689	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1791800936)	Nessus	Alma Linux 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
364682	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1791800936)	Nessus	Rocky Linux Local Security Checks	Local	high
345435	Linux Distros Unpatched Vulnerability : CVE-2026-89682	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-89682

high

Tenable Plugins

high

high

high

high

medium

high

critical

high

high