In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.

An update of the linux package has been released.

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

  - In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when     preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to
    ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the     corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls     to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx.
    This works accidentally most of the time, but it can cause us to read garbage if the second ctx came     from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This     manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-     bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int     [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40
    __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480     do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100     submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0     btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440
    __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0     extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0     writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660     wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240     ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge()     instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch.
    (CVE-2021-46984)

  - A use-after-free flaw was found in the Linux kernel's SGI GRU driver in the way the first     gru_file_unlocked_ioctl function is called by the user, where a fail pass occurs in the     gru_check_chiplet_assignment function. This flaw allows a local user to crash or potentially escalate     their privileges on the system. (CVE-2022-3424)

  - In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Fix alignment problem     in bpf_prog_test_run_skb() We got a syzkaller problem because of aarch64 alignment fault if KFENCE     enabled. When the size from user bpf program is an odd number, like 399, 407, etc, it will cause the     struct skb_shared_info's unaligned access. As seen below: BUG: KFENCE: use-after-free read in
    __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213):
    __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add     arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270     [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0     net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect     net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420     bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]     bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594     bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
    __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196,     size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc     include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline]     bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c     net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf     kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
    __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381 To fix the problem, we adjust @size so that (@size +     @hearoom) is a multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info is aligned to a     cache line. (CVE-2022-49840)

  - In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix linkwatch use-after-free     on disconnect usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On     disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to
    ->disconnect() by historic commit [PATCH] USB: usbnet, prevent exotic rtnl deadlock:
    https://git.kernel.org/tglx/history/c/0f138bbfd83c The change was made because back then, the kernel's     workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all*     work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent()     with rtnl_mutex held in ->ndo_stop(). The commit solved one problem but created another: It causes a use-     after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c: * If     the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in     their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent(). *     usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls     netif_carrier_{on,off}(). * That in turn schedules the work linkwatch_event(). Because     usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an     unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free. In 2010,     usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by     commit 23f333a2bfaf (drivers/net: don't use flush_scheduled_work()). Unfortunately the commit neglected     to move the wait back to ->ndo_stop(). Rectify that omission at long last. (CVE-2022-50220)

  - In the Linux kernel, the following vulnerability has been resolved: cifs: fix oops during encryption When     running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel     write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25:
    DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault     Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs,     pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003,     pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate:
    80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr :
    scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27:
    0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001     x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18:
    0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001     x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 :
    ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008     x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 :
    ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100     crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880     smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100     compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0     cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer     (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining     8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc'd from     crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in     smb_rqst::rq_iov... Instead, let's map the correct pages and offsets from vmalloc buffers as well in     cifs_sg_set_buf() and then avoiding such oopses. (CVE-2022-50341)

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

  - In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount     underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops     to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel     is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which     leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped.
    Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls     l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to     l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is     possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet     have session->tunnel set. Add a check for this case. (CVE-2024-49940)

  - In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue     naming and locking Recent changes are putting more pressure on THP deferred split queues: under load     revealing long-standing races, causing list_del corruptions, Bad page states and worse (I keep BUGs in     both of those, so usually don't get to see how badly they end up without). The relevant recent changes     being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP     splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo     large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line
    __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and     return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around     safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the     folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and     if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer     has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting     folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is     unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been     unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting     the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling     folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5     (mm: thp: make deferred split shrinker memcg aware): which included a check on swapcache before adding     to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with     the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on     deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (mm: split underused THPs)     avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep     the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the     existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the     queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated):
    mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio     from the deferred list, sometimes corrupting from memcg's list, like swapout. Refcount is non-zero here,     so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be     done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course     unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged     should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The     87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of     its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (mm: thp: don't need     care deferred split queue in memcg charge move path), which argued that the existence of a PMD mapping     guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly     false. Backport to 6.11 should be straightforward. Earlier backports must take care that other
    _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can     fix cornercases. (CVE-2024-53079)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: reallocate buf lists on     upgrade IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy     selected buffer and has been emptied. It violates the requirement that most of the field should stay     stable after publish. Always reallocate it instead. (CVE-2025-21836)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add sanity checks on     rdev validity There is a possibility that ulp_irq_stop and ulp_irq_start callbacks will be called when the     device is in detached state. This can cause a crash due to NULL pointer dereference as the rdev is already     freed. (CVE-2025-21901)

  - In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: Add missing NULL     ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update.
    (CVE-2025-23137)

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

  - In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount     underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops     to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel     is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which     leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped.
    Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls     l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to     l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is     possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet     have session->tunnel set. Add a check for this case. (CVE-2024-49940)

  - In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue     naming and locking Recent changes are putting more pressure on THP deferred split queues: under load     revealing long-standing races, causing list_del corruptions, Bad page states and worse (I keep BUGs in     both of those, so usually don't get to see how badly they end up without). The relevant recent changes     being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP     splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo     large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line
    __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and     return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around     safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the     folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and     if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer     has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting     folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is     unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been     unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting     the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling     folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5     (mm: thp: make deferred split shrinker memcg aware): which included a check on swapcache before adding     to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with     the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on     deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (mm: split underused THPs)     avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep     the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the     existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the     queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated):
    mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio     from the deferred list, sometimes corrupting from memcg's list, like swapout. Refcount is non-zero here,     so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be     done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course     unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged     should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The     87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of     its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (mm: thp: don't need     care deferred split queue in memcg charge move path), which argued that the existence of a PMD mapping     guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly     false. Backport to 6.11 should be straightforward. Earlier backports must take care that other
    _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can     fix cornercases. (CVE-2024-53079)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: reallocate buf lists on     upgrade IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy     selected buffer and has been emptied. It violates the requirement that most of the field should stay     stable after publish. Always reallocate it instead. (CVE-2025-21836)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add sanity checks on     rdev validity There is a possibility that ulp_irq_stop and ulp_irq_start callbacks will be called when the     device is in detached state. This can cause a crash due to NULL pointer dereference as the rdev is already     freed. (CVE-2025-21901)

  - In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: Add missing NULL     ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update.
    (CVE-2025-23137)

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.

  - drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit()     and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end()     were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-     enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures,     u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested     interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt     the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing     drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the     u64_stats update. (CVE-2026-68286)

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

ID	Name	Product	Family	Type	Severity
375113	Photon OS 5.0: Linux PHSA-2026-5.0-91-1014	Nessus	PhotonOS Local Security Checks	Local	high
375014	Photon OS 5.0: Linux PHSA-2026-5.0-92-1014	Nessus	PhotonOS Local Security Checks	Local	high
366919	Debian dla-4841 : ata-modules-6.1.0-53-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
366781	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1792239979)	Nessus	CentOS Local Security Checks	Local	high
365768	Ubuntu 26.04 LTS : Linux kernel (Azure) vulnerabilities (USN-8888-1)	Nessus	Ubuntu Local Security Checks	Local	medium
365767	Ubuntu 26.04 LTS : Linux kernel vulnerabilities (USN-8887-1)	Nessus	Ubuntu Local Security Checks	Local	medium
365463	Ubuntu 26.04 LTS : Linux kernel (OEM) vulnerabilities (USN-8889-1)	Nessus	Ubuntu Local Security Checks	Local	medium
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
352240	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1787305050)	Nessus	Rocky Linux Local Security Checks	Local	high
352220	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1787305050)	Nessus	Alma Linux Local Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
350138	openSUSE 16: cluster-md-kmp-64kb / cluster-md-kmp-azure / cluster-md-kmp-default / etc (openSUSE-SU-2026:21910-1)	Nessus	SuSE Local Security Checks	Local	high
347900	SUSE SLED15 / SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:4254-1)	Nessus	SuSE Local Security Checks	Local	high
334291	Linux Distros Unpatched Vulnerability : CVE-2026-68286	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-68286

high

Tenable Plugins

high

high

high

high

medium

medium

medium

high

high

high

high

high

high

high

high