In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use active memslots for the per-vCPU MMIO cache KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1. Commit 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") added the SMM address space, these helpers were not converted to use the active memslots. Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO. Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination. Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address spaces, so the generation also distinguishes the normal and SMM views. This matches the MMIO SPTE cache, which already uses kvm_vcpu_memslots(). On an unpatched current-mainline kernel, a regression test that fills the cache in SMM and updates only the SMM memslots fails the intended RAM write and triggers the kvm_mmu_write_protect_fault() warning. With this change, the same test completes the RAM write without a warning. The x86/smm_test, set_memory_region_test, and memslot_modification_stress_test selftests also pass.

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-3389 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    vhost: fix vhost_get_avail_idx for a non empty ring (CVE-2026-74356)

    In the Linux kernel, the following vulnerability has been resolved:

    sctp: validate cookie AUTH state before use (CVE-2026-74752)

    In the Linux kernel, the following vulnerability has been resolved:

    smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() (CVE-2026-89633)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSD: Prevent client use-after-free during delegation revoke (CVE-2026-89659)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSD: Prevent client use-after-free during blocked-lock reaping (CVE-2026-90036)

    In the Linux kernel, the following vulnerability has been resolved:

    smb: client: reject out-of-bounds DataOffset in CIFSSMBRead() (CVE-2026-97563)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Preserve inner map identity in callback frames (CVE-2026-98033)

    In the Linux kernel, the following vulnerability has been resolved:

    smb: client: fix create context out-of-bounds reads (CVE-2026-98454)

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: arm64: Transfer the hyp stack pages out of the host stage-2 (CVE-2026-98466)

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN (CVE-2026-98715)

    In the Linux kernel, the following vulnerability has been resolved:

    tipc: prevent GCM nonce reuse on peer key changes (CVE-2026-98805)

    In the Linux kernel, the following vulnerability has been resolved:

    sctp: check RCV_SHUTDOWN after the sendmsg connect wait (CVE-2026-98846)

    In the Linux kernel, the following vulnerability has been resolved:

    ipvs: bound LBLCR and LBLC cache growth (CVE-2026-98857)

    In the Linux kernel, the following vulnerability has been resolved:

    tipc: hold a reference to nodes found by link name (CVE-2026-99053)

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: x86: Use active memslots for the per-vCPU MMIO cache (CVE-2026-99082)

Tenable has extracted the preceding description block directly from the tested product 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 version of kernel installed on the remote host is prior to 5.10.272-274.1151. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.10-2026-138 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    cifs: validate DFS referral string offsets (CVE-2026-72318)

    In the Linux kernel, the following vulnerability has been resolved:

    sctp: validate cookie AUTH state before use (CVE-2026-74752)

    In the Linux kernel, the following vulnerability has been resolved:

    svcrdma: Reject inline replies that overflow the pull-up buffer (CVE-2026-89530)

    In the Linux kernel, the following vulnerability has been resolved:

    smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() (CVE-2026-89633)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSD: Prevent client use-after-free during delegation revoke (CVE-2026-89659)

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save (CVE-2026-89912)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSD: Prevent client use-after-free during blocked-lock reaping (CVE-2026-90036)

    In the Linux kernel, the following vulnerability has been resolved:

    smb: client: reject out-of-bounds DataOffset in CIFSSMBRead() (CVE-2026-97563)

    In the Linux kernel, the following vulnerability has been resolved:

    smb: client: fix server->total_read for compound encrypted PDUs (CVE-2026-98167)

    In the Linux kernel, the following vulnerability has been resolved:

    RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access (CVE-2026-98365)

    In the Linux kernel, the following vulnerability has been resolved:

    smb: client: fix create context out-of-bounds reads (CVE-2026-98454)

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN (CVE-2026-98715)

    In the Linux kernel, the following vulnerability has been resolved:

    tipc: prevent GCM nonce reuse on peer key changes (CVE-2026-98805)

    In the Linux kernel, the following vulnerability has been resolved:

    sctp: check RCV_SHUTDOWN after the sendmsg connect wait (CVE-2026-98846)

    In the Linux kernel, the following vulnerability has been resolved:

    tipc: hold a reference to nodes found by link name (CVE-2026-99053)

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: x86: Use active memslots for the per-vCPU MMIO cache (CVE-2026-99082)

Tenable has extracted the preceding description block directly from the tested product 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 AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1793866396 advisory.

  - 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: iommufd: Prevent ALIGN() overflow When     allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to     ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using     get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length     earlier either. Consolidate the two copies of this code under a single helper. This bug would allow     userspace to create a mapping that overlaps with some other mapping or a reserved range. (CVE-2025-38688)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in     ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is     not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-39991)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-     bounds writes in handle_auth_session_key() The len field originates from untrusted network packets.
    Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection     secret or processing service tickets. [ idryomov: changelog ] (CVE-2025-68284)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on     duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on     every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
    Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to     65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the     affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs     before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents     the underflow path. (CVE-2026-31662)

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:1793866396 advisory.

  - 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: iommufd: Prevent ALIGN() overflow When     allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to     ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using     get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length     earlier either. Consolidate the two copies of this code under a single helper. This bug would allow     userspace to create a mapping that overlaps with some other mapping or a reserved range. (CVE-2025-38688)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in     ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is     not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-39991)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-     bounds writes in handle_auth_session_key() The len field originates from untrusted network packets.
    Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection     secret or processing service tickets. [ idryomov: changelog ] (CVE-2025-68284)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on     duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on     every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
    Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to     65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the     affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs     before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents     the underflow path. (CVE-2026-31662)

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 10 / 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-500572 advisory.

    - NFSD: Define actions for the new time_deleg FATTR4 attributes (Chuck Lever)  [Orabug: 39004166]     {CVE-2025-40326}
    - ipv4: free inet_opt and ireq_opt after an RCU grace period (Eric Dumazet)  [Orabug: 40165787]     {CVE-2026-98432}
    - ipv4: validate checksum_start before completing checksum (Michael S. Tsirkin)  [Orabug: 40165809]     {CVE-2026-99999}
    - mm/pagewalk: fix stale walk->action escaping walk_pmd_range() (Hyunwoo Kim)  [Orabug: 40022020]     {CVE-2026-89754}

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 Oracle Linux 8 / 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-500574 advisory.

    - ipv4: validate checksum_start before completing checksum (Michael S. Tsirkin)  [Orabug: 40165811]     {CVE-2026-99999}
    - ipv4: free inet_opt and ireq_opt after an RCU grace period (Eric Dumazet)  [Orabug: 40165788]     {CVE-2026-98432}
    - exec: Cleanup POSIX timers right after de_thread() (Hyunwoo Kim)  [Orabug: 40120750]  {CVE-2026-98260}

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 CentOS Linux 8.4 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.4:CLSA-2026:1793364521 advisory.

  - An out-of-bounds access flaw was found in the Linux kernel's implementation of the eBPF code verifier in     the way a user running the eBPF script calls dev_map_init_map or sock_map_alloc. This flaw allows a local     user to crash the system or possibly escalate their privileges. The highest threat from this vulnerability     is to confidentiality, integrity, as well as system availability. (CVE-2021-20268)

  - In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: remove block_cb     from driver_list before freeing Error handler of tcf_block_bind() frees the whole bo->cb_list on error.
    However, by that time the flow_block_cb instances are already in the driver list because driver     ndo_setup_tc() callback is called before that up the call chain in tcf_block_offload_cmd(). This leaves     dangling pointers to freed objects in the list and causes use-after-free[0]. Fix it by also removing     flow_block_cb instances from driver_list before deallocating them. [0]: [ 279.868433]     ================================================================== [ 279.869964] BUG: KASAN: slab-use-     after-free in flow_block_cb_setup_simple+0x631/0x7c0 [ 279.871527] Read of size 8 at addr ffff888147e2bf20     by task tc/2963 [ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4 [ 279.874273] Hardware     name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [     279.876295] Call Trace: [ 279.876882] <TASK> [ 279.877413] dump_stack_lvl+0x33/0x50 [ 279.878198]     print_report+0xc2/0x610 [ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0 [ 279.879994]     kasan_report+0xae/0xe0 [ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0 [ 279.881744] ?     mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core] [ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0     [ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0 [ 279.885037] ? tcf_block_setup+0x6b0/0x6b0 [     279.885901] ? mutex_lock+0x7d/0xd0 [ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0 [     279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress] [ 279.888846] tcf_block_get_ext+0x61c/0x1200 [     279.889711] ingress_init+0x112/0x1c0 [sch_ingress] [ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress] [     279.891701] qdisc_create+0x401/0xea0 [ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470 [ 279.893473]     tc_modify_qdisc+0x6f7/0x16d0 [ 279.894344] ? tc_get_qdisc+0xac0/0xac0 [ 279.895213] ? mutex_lock+0x7d/0xd0     [ 279.896005] ? __mutex_lock_slowpath+0x10/0x10 [ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0 [ 279.897770]     ? rtnl_calcit.isra.0+0x2b0/0x2b0 [ 279.898672] ? __sys_sendmsg+0xb5/0x140 [ 279.899494] ?     do_syscall_64+0x3d/0x90 [ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 279.901337] ?     kasan_save_stack+0x2e/0x40 [ 279.902177] ? kasan_save_stack+0x1e/0x40 [ 279.903058] ?     kasan_set_track+0x21/0x30 [ 279.903913] ? kasan_save_free_info+0x2a/0x40 [ 279.904836] ?
    ____kasan_slab_free+0x11a/0x1b0 [ 279.905741] ? kmem_cache_free+0x179/0x400 [ 279.906599]     netlink_rcv_skb+0x12c/0x360 [ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0 [ 279.908360] ?     netlink_ack+0x1550/0x1550 [ 279.909192] ? rhashtable_walk_peek+0x170/0x170 [ 279.910135] ?     kmem_cache_alloc_node+0x1af/0x390 [ 279.911086] ? _copy_from_iter+0x3d6/0xc70 [ 279.912031]     netlink_unicast+0x553/0x790 [ 279.912864] ? netlink_attachskb+0x6a0/0x6a0 [ 279.913763] ?     netlink_recvmsg+0x416/0xb50 [ 279.914627] netlink_sendmsg+0x7a1/0xcb0 [ 279.915473] ?     netlink_unicast+0x790/0x790 [ 279.916334] ? iovec_from_user.part.0+0x4d/0x220 [ 279.917293] ?     netlink_unicast+0x790/0x790 [ 279.918159] sock_sendmsg+0xc5/0x190 [ 279.918938]
    ____sys_sendmsg+0x535/0x6b0 [ 279.919813] ? import_iovec+0x7/0x10 [ 279.920601] ? kernel_sendmsg+0x30/0x30     [ 279.921423] ? __copy_msghdr+0x3c0/0x3c0 [ 279.922254] ? import_iovec+0x7/0x10 [ 279.923041]
    ___sys_sendmsg+0xeb/0x170 [ 279.923854] ? copy_msghdr_from_user+0x110/0x110 [ 279.924797] ?
    ___sys_recvmsg+0xd9/0x130 [ 279.925630] ? __perf_event_task_sched_in+0x183/0x470 [ 279.926656] ?
    ___sys_sendmsg+0x170/0x170 [ 279.927529] ? ctx_sched_in+0x530/0x530 [ 279.928369] ?     update_curr+0x283/0x4f0 [ 279.929185] ? perf_event_update_userpage+0x570/0x570 [ 279.930201] ?
    __fget_light+0x57/0x520 [ 279.931023] ? __switch_to+0x53d/0xe70 [ 27 ---truncated--- (CVE-2023-54193)

  - In the Linux kernel, the following vulnerability has been resolved: SUNRPC: make sure cache entry active     before cache_show The function `c_show` was called with protection from RCU. This only ensures that `cp`     will not be freed. Therefore, the reference count for `cp` can drop to zero, which will trigger a refcount     use-after-free warning when `cache_get` is called. To resolve this issue, use `cache_get_rcu` to ensure     that `cp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822     Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS     1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Call Trace: <TASK> c_show+0x2fc/0x380     [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530     ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e (CVE-2024-53174)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: fix missing length     checks in hidp_input_report() hidp_input_report() reads keyboard and mouse payload data from an skb     without first verifying that skb->len contains enough data. hidp_recv_intr_frame() pulls the 1-byte HIDP     header before dispatching to hidp_input_report(). If a paired device sends a truncated packet, the handler     reads beyond the valid skb data, resulting in an out-of-bounds read of skb data. The OOB bytes may be     interpreted as phantom key presses or spurious mouse movement. Replace the open-coded length tracking and     pointer arithmetic with skb_pull_data() calls. skb_pull_data() returns NULL if the requested bytes are not     present, eliminating the need for a manual size variable and the separate skb->len guard. (CVE-2026-63947)

  - In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index     in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using     pmdata->svid_index as an array index without bounds validation: paltmode->svid =     pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it     results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside     struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads     the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-     supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving     svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen     SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that     pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the     pmdata->svids array inside svdm_consume_modes(). (CVE-2026-64330)

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

The CentOS Linux 8.5 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.5:CLSA-2026:1793359087 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: remove block_cb     from driver_list before freeing Error handler of tcf_block_bind() frees the whole bo->cb_list on error.
    However, by that time the flow_block_cb instances are already in the driver list because driver     ndo_setup_tc() callback is called before that up the call chain in tcf_block_offload_cmd(). This leaves     dangling pointers to freed objects in the list and causes use-after-free[0]. Fix it by also removing     flow_block_cb instances from driver_list before deallocating them. [0]: [ 279.868433]     ================================================================== [ 279.869964] BUG: KASAN: slab-use-     after-free in flow_block_cb_setup_simple+0x631/0x7c0 [ 279.871527] Read of size 8 at addr ffff888147e2bf20     by task tc/2963 [ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4 [ 279.874273] Hardware     name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [     279.876295] Call Trace: [ 279.876882] <TASK> [ 279.877413] dump_stack_lvl+0x33/0x50 [ 279.878198]     print_report+0xc2/0x610 [ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0 [ 279.879994]     kasan_report+0xae/0xe0 [ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0 [ 279.881744] ?     mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core] [ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0     [ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0 [ 279.885037] ? tcf_block_setup+0x6b0/0x6b0 [     279.885901] ? mutex_lock+0x7d/0xd0 [ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0 [     279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress] [ 279.888846] tcf_block_get_ext+0x61c/0x1200 [     279.889711] ingress_init+0x112/0x1c0 [sch_ingress] [ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress] [     279.891701] qdisc_create+0x401/0xea0 [ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470 [ 279.893473]     tc_modify_qdisc+0x6f7/0x16d0 [ 279.894344] ? tc_get_qdisc+0xac0/0xac0 [ 279.895213] ? mutex_lock+0x7d/0xd0     [ 279.896005] ? __mutex_lock_slowpath+0x10/0x10 [ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0 [ 279.897770]     ? rtnl_calcit.isra.0+0x2b0/0x2b0 [ 279.898672] ? __sys_sendmsg+0xb5/0x140 [ 279.899494] ?     do_syscall_64+0x3d/0x90 [ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 279.901337] ?     kasan_save_stack+0x2e/0x40 [ 279.902177] ? kasan_save_stack+0x1e/0x40 [ 279.903058] ?     kasan_set_track+0x21/0x30 [ 279.903913] ? kasan_save_free_info+0x2a/0x40 [ 279.904836] ?
    ____kasan_slab_free+0x11a/0x1b0 [ 279.905741] ? kmem_cache_free+0x179/0x400 [ 279.906599]     netlink_rcv_skb+0x12c/0x360 [ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0 [ 279.908360] ?     netlink_ack+0x1550/0x1550 [ 279.909192] ? rhashtable_walk_peek+0x170/0x170 [ 279.910135] ?     kmem_cache_alloc_node+0x1af/0x390 [ 279.911086] ? _copy_from_iter+0x3d6/0xc70 [ 279.912031]     netlink_unicast+0x553/0x790 [ 279.912864] ? netlink_attachskb+0x6a0/0x6a0 [ 279.913763] ?     netlink_recvmsg+0x416/0xb50 [ 279.914627] netlink_sendmsg+0x7a1/0xcb0 [ 279.915473] ?     netlink_unicast+0x790/0x790 [ 279.916334] ? iovec_from_user.part.0+0x4d/0x220 [ 279.917293] ?     netlink_unicast+0x790/0x790 [ 279.918159] sock_sendmsg+0xc5/0x190 [ 279.918938]
    ____sys_sendmsg+0x535/0x6b0 [ 279.919813] ? import_iovec+0x7/0x10 [ 279.920601] ? kernel_sendmsg+0x30/0x30     [ 279.921423] ? __copy_msghdr+0x3c0/0x3c0 [ 279.922254] ? import_iovec+0x7/0x10 [ 279.923041]
    ___sys_sendmsg+0xeb/0x170 [ 279.923854] ? copy_msghdr_from_user+0x110/0x110 [ 279.924797] ?
    ___sys_recvmsg+0xd9/0x130 [ 279.925630] ? __perf_event_task_sched_in+0x183/0x470 [ 279.926656] ?
    ___sys_sendmsg+0x170/0x170 [ 279.927529] ? ctx_sched_in+0x530/0x530 [ 279.928369] ?     update_curr+0x283/0x4f0 [ 279.929185] ? perf_event_update_userpage+0x570/0x570 [ 279.930201] ?
    __fget_light+0x57/0x520 [ 279.931023] ? __switch_to+0x53d/0xe70 [ 27 ---truncated--- (CVE-2023-54193)

  - In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in     pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls     pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before     trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the     tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).
    (CVE-2026-63800)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: fix missing length     checks in hidp_input_report() hidp_input_report() reads keyboard and mouse payload data from an skb     without first verifying that skb->len contains enough data. hidp_recv_intr_frame() pulls the 1-byte HIDP     header before dispatching to hidp_input_report(). If a paired device sends a truncated packet, the handler     reads beyond the valid skb data, resulting in an out-of-bounds read of skb data. The OOB bytes may be     interpreted as phantom key presses or spurious mouse movement. Replace the open-coded length tracking and     pointer arithmetic with skb_pull_data() calls. skb_pull_data() returns NULL if the requested bytes are not     present, eliminating the need for a manual size variable and the separate skb->len guard. (CVE-2026-63947)

  - In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after     skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and     iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can     reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call.
    Remove skb_reset_network_header() calls which were not needed. (CVE-2026-63994)

  - In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on     meter attach failure While attaching a newly created meter attach_meter() function makes the new meter     visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an     error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter)     on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is     never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But     the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in     ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508     Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions     (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584)     ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated     by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set     (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree     (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ...
    netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible     until all the checks are done and the function can't fail anymore. This also makes sure the hash value     is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as     ZDI-CAN-31642. (CVE-2026-74465)

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

The CentOS Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS-STREAM8:CLSA-2026:1793362651 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in     gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the     superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake     up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp     via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota     objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or     if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait     completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are     still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU     callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed. (CVE-2026-63804)

  - In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index     in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using     pmdata->svid_index as an array index without bounds validation: paltmode->svid =     pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it     results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside     struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads     the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-     supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving     svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen     SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that     pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the     pmdata->svids array inside svdm_consume_modes(). (CVE-2026-64330)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: hold event_mutex while     checkpointing CRIU events kfd_criu_checkpoint_events() counts the entries in p->event_idr via     kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it.
    Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event     create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex,     so a second thread in the same process can insert or remove events between the count and the walk. If an     event is inserted, the walk iterates more entries than were counted and writes past the end of the     ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold     p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock     is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex     and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted     and no deadlock is introduced. (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)     (CVE-2026-74446)

  - In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on     meter attach failure While attaching a newly created meter attach_meter() function makes the new meter     visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an     error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter)     on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is     never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But     the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in     ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508     Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions     (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584)     ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated     by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set     (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree     (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ...
    netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible     until all the checks are done and the function can't fail anymore. This also makes sure the hash value     is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as     ZDI-CAN-31642. (CVE-2026-74465)

  - In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use     system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device     drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via     vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global     system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving     page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending     (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page     reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free /     General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address     0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [     196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073]     virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0     Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses     page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting     worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM     during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the     driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen     by the PM core before this * function is called. */ Testing: I have verified these fixes using Google's     virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning     memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for     the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting     worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are     no longer reproducible. (CVE-2026-74481)

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:1793333110 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: dma-debug: don't call
    __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk ->     serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a     reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab     free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock     scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The     existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}:
    _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8     dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc     qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54     handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40     generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0     el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8
    ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80     qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0     vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90     register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424     platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114     driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8
    __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0     device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8     of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac     geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}:
    __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454     console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc
    _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4     dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm]     msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c     drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key -->     free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock);
    lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace:
    dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24     print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c     lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated--- (CVE-2023-52516)

  - In the Linux kernel, the following vulnerability has been resolved: USB: sisusbvga: Add endpoint checks     The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver: ------------[ cut here     ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 26 at     drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU:
    1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0 Hardware name: Google     Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Workqueue: usb_hub_wq hub_event RIP:
    0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18     e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff     ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff888012783a80 RSI: ffffffff816680ec     RDI: fffff52000143d95 RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000 R10:
    0000000080000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff888017d33370 R14: 0000000000000003     R15: ffff888021213600 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sisusb_bulkout_msg     drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230     drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet     drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice     drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000     drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2     drivers/usb/misc/sisusbvga/sisusbvga.c:2869 ... The problem was caused by the fact that the driver does     not check whether the endpoints it uses are actually present and have the appropriate types. This can be     fixed by adding a simple check of the endpoints. (CVE-2023-54213)

  - In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: use the backlog     for mirred ingress The test Davide added in commit ca22da2fbd69 (act_mirred: use the backlog for nested     calls to mirred ingress) hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv ->     tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that     if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which     generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks     is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress ->     ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the     backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround     does not seem to address the issue. (CVE-2024-26740)

  - In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: fix a bug calling     wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa     node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's     because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before     calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF:
    supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops:
    0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name:
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 >     RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS:
    00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI:
    0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff     > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14:
    0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000)     knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3:
    000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000     > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: >     <TASK> > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault >     ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault >     exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP:
    002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0     > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08:
    0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000     > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 > </TASK> (CVE-2024-26783)

  - In the Linux kernel, the following vulnerability has been resolved: vfs: Don't evict inode under the inode     lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable     inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try     getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by     function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode     lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru     traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode     lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting     context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is     added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 >     /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg     prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state     inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink =     0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode     ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(i_ea) ---- AA deadlock dispose_list // cannot be executed by prune_icache_sb     wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file     deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode     reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting     function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a     xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added     into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 >     /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia     prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state     inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm     file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia)     make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode |     ubifs_jnl_delete_inode(ib)  ubifs_jnl_write_inode ABBA deadlock -----make_reservation(BASEHD)     dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock     by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate(
    ---truncated--- (CVE-2024-45003)

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.

  - KVM: x86: Use active memslots for the per-vCPU MMIO cache KVM tags the per-vCPU MMIO cache with a memslot     generation so that a memslot update invalidates cached MMIO information. Both the fill and validation     paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in     SMM and using address space 1. Commit 56f17dd3fbc4 (kvm: x86: fix stale mmio cache bug) added the     memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When     commit 699023e23965 (KVM: x86: add SMM to the MMU role, support SMRAM address space) added the SMM     address space, these helpers were not converted to use the active memslots. Consequently, an update to the     SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to     the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to     userspace as KVM_EXIT_MMIO. Completing that exit through the VMM's RAM address space writes the backing     page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can     continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in     kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination. Use the vCPU's active     memslots when caching and validating the entry. Memslot generations are unique across address spaces, so     the generation also distinguishes the normal and SMM views. This matches the MMIO SPTE cache, which     already uses kvm_vcpu_memslots(). On an unpatched current-mainline kernel, a regression test that fills     the cache in SMM and updates only the SMM memslots fails the intended RAM write and triggers the     kvm_mmu_write_protect_fault() warning. With this change, the same test completes the RAM write without a     warning. The x86/smm_test, set_memory_region_test, and memslot_modification_stress_test selftests also     pass. (CVE-2026-99082)

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

ID	Name	Product	Family	Type	Severity
379876	Amazon Linux 2 : kernel (ALASKERNEL-5.15-2026-121)	Nessus	Amazon Linux Local Security Checks	Local	critical
377932	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2026-3389)	Nessus	Amazon Linux Local Security Checks	Local	critical
377922	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2026-138)	Nessus	Amazon Linux Local Security Checks	Local	critical
377900	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3402)	Nessus	Amazon Linux Local Security Checks	Local	high
376433	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793866396)	Nessus	Alma Linux Local Security Checks	Local	high
376432	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793866396)	Nessus	Rocky Linux Local Security Checks	Local	high
375469	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500572)	Nessus	Oracle Linux Local Security Checks	Local	medium
375468	Oracle Linux 8 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500574)	Nessus	Oracle Linux Local Security Checks	Local	high
374301	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1793364521)	Nessus	CentOS Local Security Checks	Local	high
374206	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1793359087)	Nessus	CentOS Local Security Checks	Local	critical
374204	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1793362651)	Nessus	CentOS Local Security Checks	Local	high
374135	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1793333110)	Nessus	Alma Linux Local Security Checks	Local	high
371494	Linux Distros Unpatched Vulnerability : CVE-2026-99082	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-99082

high

Tenable Plugins

critical

critical

critical

high

high

high

medium

high

high

critical

high

high

high