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

  - In the Linux kernel, the following vulnerability has been resolved: tracing/histogram: Fix a potential     memory leak for kstrdup() kfree() is missing on an error path to free the memory allocated by kstrdup(): p     = param = kstrdup(data->params[i], GFP_KERNEL); So it is better to free it via kfree(p). (CVE-2022-48768)

  - In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer     dereference in can_rx_register() It causes NULL pointer dereference when testing as following: (a) use     syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket. (b) use syscall(__NR_sendmsg, ...) to     create bond link device and vxcan link device, and bind vxcan device to bond device (can also use     ifenslave command to bind vxcan device to bond device). (c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to     create CAN socket. (d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket. The bond device     invokes the can-raw protocol registration interface to receive CAN packets. However, ml_priv is not     allocated to the dev, dev_rcv_lists is assigned to NULL in can_rx_register(). In this case, it will occur     the NULL pointer dereference issue. The following is the stack information: BUG: kernel NULL pointer     dereference, address: 0000000000000008 PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0 Oops: 0000 [#1]     PREEMPT SMP RIP: 0010:can_rx_register+0x12d/0x1e0 Call Trace: <TASK> raw_enable_filters+0x8d/0x120     raw_enable_allfilters+0x3b/0x130 raw_bind+0x118/0x4f0 __sys_bind+0x163/0x1a0 __x64_sys_bind+0x1e/0x30     do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> (CVE-2022-49863)

  - In the Linux kernel, the following vulnerability has been resolved: net/tipc: fix slab-use-after-free Read     in tipc_aead_encrypt_done Syzbot reported a slab-use-after-free with the following call trace:
    ================================================================== BUG: KASAN: slab-use-after-free in     tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task     kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601     tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete     include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85     cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266     cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231     Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0     net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650     net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670     net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110     unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323
    __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557     tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119     ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640     process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace,     tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip     netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1     tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip     netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that,     simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the     cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout     tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt     // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt //     encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger     cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net     reference count before encrypt. (CVE-2025-38052)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix possible crashes     on eir_create_adv_data eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking     if that would fit. (CVE-2025-38303)

  - In the Linux kernel, the following vulnerability has been resolved: gve: prevent ethtool ops after     shutdown A crash can occur if an ethtool operation is invoked after shutdown() is called. shutdown() is     invoked during system shutdown to stop DMA operations without performing expensive deallocations. It is     discouraged to unregister the netdev in this path, so the device may still be visible to userspace and     kernel helpers. In gve, shutdown() tears down most internal data structures. If an ethtool operation is     dispatched after shutdown(), it will dereference freed or NULL pointers, leading to a kernel panic. While     graceful shutdown normally quiesces userspace before invoking the reboot syscall, forced shutdowns (as     observed on GCP VMs) can still trigger this path. Fix by calling netif_device_detach() in shutdown(). This     marks the device as detached so the ethtool ioctl handler will skip dispatching operations to the driver.
    (CVE-2025-38735)

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

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: validate user input for     expected length I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436     (bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt) setsockopt() @optlen argument should be taken into     account before copying data. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset     include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr     include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace     net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0     net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238     CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name:
    Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack     lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description     mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180     mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70     mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr     include/linux/sockptr.h:55 [inline] do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]     do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0     net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
    __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline]
    __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340     do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Code: 28 00 00     00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c     24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8     EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX:
    00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a     R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12:
    0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 </TASK> Allocated by     task 7238: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68     poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387     kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:4069 [inline]
    __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 kmalloc_noprof include/linux/slab.h:664 [inline]
    __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720     net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343     [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340     do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a The buggy address belongs to the object     at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes     inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1) The buggy address belongs to the     physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73     flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000000     ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff     00 ---truncated--- (CVE-2024-35896)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-     bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible     out-of-bounds access in the callout. [ idryomov: changelog ] (CVE-2026-22984)

  - In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before returning     from fuse_ref_folio() fuse_ref_folio() unlocks the request but does not re-lock it before returning.
    fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the     args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free     issues. Fix this by locking the request in fuse_ref_folio() before returning. (CVE-2026-64266)

  - In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own     transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed     against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through     its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address     Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for     the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A     single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L     differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the     transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP     then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and     sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and     plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(),     keeping only the pointer that is no longer on the list, removes every real transport, leaving the     association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a     DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-     address guard, so the wildcard branch can never reuse a freed transport. (CVE-2026-64564)

  - In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list     against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked     list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every     caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That     invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps     rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through     tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls     qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different     CPUs, each adding a flower filter with a police action carrying the same rate, then race on     qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k     struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is     shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160     qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0     tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0     tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size     2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL)     allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an     identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is     leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock. (CVE-2026-68138)

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

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: add RCU protection to     mld_newpack() mld_newpack() can be called without RTNL or RCU being held. Note that we no longer can use     sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use     alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection. (CVE-2025-21758)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: extend RCU protection in     igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we     can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use     sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use     alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection. (CVE-2025-21759)

  - In the Linux kernel, the following vulnerability has been resolved: ndisc: extend RCU protection in     ndisc_send_skb() ndisc_send_skb() can be called without RTNL or RCU held. Acquire rcu_read_lock() earlier,     so that we can use dev_net_rcu() and avoid a potential UAF. (CVE-2025-21760)

  - In the Linux kernel, the following vulnerability has been resolved: openvswitch: use RCU protection in     ovs_vport_cmd_fill_info() ovs_vport_cmd_fill_info() can be called without RTNL or RCU. Use RCU protection     and dev_net_rcu() to avoid potential UAF. (CVE-2025-21761)

  - In the Linux kernel, the following vulnerability has been resolved: arp: use RCU protection in arp_xmit()     arp_xmit() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.
    (CVE-2025-21762)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
365463	Ubuntu 26.04 LTS : Linux kernel (OEM) vulnerabilities (USN-8889-1)	Nessus	Ubuntu Local Security Checks	2026/10/13	2026/10/13	medium
360902	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1788168285)	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/1	high
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
366919	Debian dla-4841 : ata-modules-6.1.0-53-armmp-di - security update	Nessus	Debian Local Security Checks	2026/10/17	2026/10/17	high
352748	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1787292462)	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
351684	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1787572220)	Nessus	CentOS Local Security Checks	2026/9/30	2026/10/18	critical

检测

插件搜索

medium

high

high

high

high

critical