Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - MD/RAID10：修正捨棄失敗時的writes_pending和屏障參照洩露 raid10_make_request（） 在呼叫 raid10_handle_discard（） 之前使用 md_write_start（） 取得writes_pending參照）。raid10_handle_discard（） 中的幾個失敗路徑完成了 bio 並返回而不釋放相應的引用，導致跳過了 md_write_end（）。從這些失敗路徑返回之前，請先呼叫 md_write_end（），以保持writes_pending帳戶平衡。此外，在 wait_barrier（） 成功之後，可能會發生捨棄分割分配失敗。這些路徑會在不呼叫 allow_barrier（） 的情況下傳回，從而洩漏相關聯的屏障參照。在從這些路徑返回之前釋放障礙。（CVE-2026-72438）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Rocky Linux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1791800936 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：kunit: Fix potential null dereference in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

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

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

  - 已解決 Linux 核心中的下列弱點：devlink: fix xa_alloc_cyclic() error handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
    (CVE-2025-22017)

  - 已解決 Linux 核心中的下列弱點：drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1789898700 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：ceph: fix possible deadlock when holding Fwb to get inline_data 1, mount with wsync. 2, create a file with O_RDWR, and the request was sent to mds.0: ceph_atomic_open()--> ceph_mdsc_do_request(openc) finish_open(file, dentry, ceph_open)--> ceph_open()--> ceph_init_file()--> ceph_init_file_info()--> ceph_uninline_data()--> { ... if (inline_version == 1 || /* initial version, no data */ inline_version == CEPH_INLINE_NONE) goto out_unlock; ... } The inline_version will be 1, which is the initial version for the new create file. And here the ci->i_inline_version will keep with 1, it's buggy. 3, buffer write to the file immediately:
    ceph_write_iter()--> ceph_get_caps(file, need=Fw, want=Fb, ...); generic_perform_write()--> a_ops->write_begin()--> ceph_write_begin()--> netfs_write_begin()--> netfs_begin_read()--> netfs_rreq_submit_slice()--> netfs_read_from_server()--> rreq->netfs_ops->issue_read()--> ceph_netfs_issue_read()--> { ... if (ci->i_inline_version != CEPH_INLINE_NONE && ceph_netfs_issue_op_inline(subreq)) return; ... } ceph_put_cap_refs(ci, Fwb); The ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to mds.1. 4, then the mds.1 will request the rd lock for CInode::filelock from the auth mds.0, the mds.0 will do the CInode::filelock state transation from excl --> sync, but it need to revoke the Fxwb caps back from the clients. While the kernel client has aleady held the Fwb caps and waiting for the getattr(Fsr). It's deadlock! URL:
    https://tracker.ceph.com/issues/55377 (CVE-2022-49296)

  - 已解決 Linux 核心中的下列弱點：tracing: Fix reading strings from synthetic events The follow commands caused a crash: # cd /sys/kernel/tracing # echo 's:open char file[]' > dynamic_events # echo 'hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)' > events/syscalls/sys_enter_openat/trigger' # echo 1 > events/synthetic/open/enable BOOM! The problem is that the synthetic event field char file[] will read the value given to it as a string without any memory checks to make sure the address is valid. The above example will pass in the user space address and the sythetic event code will happily call strlen() on it and then strscpy() where either one will cause an oops when accessing user space addresses. Use the helper functions from trace_kprobe and trace_eprobe that can read strings safely (and actually succeed when the address is from user space and the memory is mapped in). Now the above can show: packagekitd-1721 [000] ...2. 104.597170: open:
    file=/usr/lib/rpm/fileattrs/cmake.attr in:imjournal-978 [006] ...2. 104.599642: open:
    file=/var/lib/rsyslog/imjournal.state.tmp packagekitd-1721 [000] ...2. 104.626308: open:
    file=/usr/lib/rpm/fileattrs/debuginfo.attr (CVE-2022-50255)

  - 已解決 Linux 核心中的下列弱點：hwrng: core - Fix page fault dead lock on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user. (CVE-2023-52615)

  - 已解決 Linux 核心中的下列弱點：fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues. According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision new=00000024 old=00000022 ...... INFO: task mount:1148 blocked for more than 122 seconds. Not tainted 6.1.0-rc6+ #1 task:mount state:D stack:0 pid:1148 ppid:1 Call Trace: <TASK> __schedule+0x2f6/0xb80 schedule+0x67/0xe0 fscache_wait_on_volume_collision.cold+0x80/0x82 __fscache_acquire_volume+0x40d/0x4e0 erofs_fscache_register_volume+0x51/0xe0 [erofs] erofs_fscache_register_fs+0x19c/0x240 [erofs] erofs_fc_fill_super+0x746/0xaf0 [erofs] vfs_get_super+0x7d/0x100 get_tree_nodev+0x16/0x20 erofs_fc_get_tree+0x20/0x30 [erofs] vfs_get_tree+0x24/0xb0 path_mount+0x2fa/0xa90 do_mount+0x7c/0xa0
    __x64_sys_mount+0x8b/0xe0 do_syscall_64+0x30/0x60 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Considering that wake_up_bit() is more selective, so fix it by using wait_on_bit() instead of wait_var_event() to wait for the freeing of relinquished volume. In addition because waitqueue_active() is used in wake_up_bit() and clear_bit() doesn't imply any memory barrier, use clear_and_wake_up_bit() to add the missing memory barrier between cursor->flags and waitqueue_active(). (CVE-2023-52982)

  - 已解決 Linux 核心中的下列弱點：Bluetooth: ISO: fix iso_conn related locking and validity issues sk->sk_state indicates whether iso_pi(sk)->conn is valid. Operations that check/update sk_state and access conn should hold lock_sock, otherwise they can race. The order of taking locks is hci_dev_lock > lock_sock > iso_conn_lock, which is how it is in connect/disconnect_cfm -> iso_conn_del -> iso_chan_del. Fix locking in iso_connect_cis/bis and sendmsg/recvmsg to take lock_sock around updating sk_state and conn. iso_conn_del must not occur during iso_connect_cis/bis, as it frees the iso_conn. Hold hdev->lock longer to prevent that. This should not reintroduce the issue fixed in commit 241f51931c35 (Bluetooth: ISO: Avoid circular locking dependency), since the we acquire locks in order.
    We retain the fix in iso_sock_connect to release lock_sock before iso_connect_* acquires hdev->lock.
    Similarly for commit 6a5ad251b7cd (Bluetooth: ISO: Fix possible circular locking dependency). We retain the fix in iso_conn_ready to not acquire iso_conn_lock before lock_sock. iso_conn_add shall return iso_conn with valid hcon. Make it so also when reusing an old CIS connection waiting for disconnect timeout (see __iso_sock_close where conn->hcon is set to NULL). Trace with iso_conn_del after iso_chan_add in iso_connect_cis: =============================================================== iso_sock_create:771:
    sock 00000000be9b69b7 iso_sock_init:693: sk 000000004dff667e iso_sock_bind:827: sk 000000004dff667e 70:1a:b8:98:ff:a2 type 1 iso_sock_setsockopt:1289: sk 000000004dff667e iso_sock_setsockopt:1289: sk 000000004dff667e iso_sock_setsockopt:1289: sk 000000004dff667e iso_sock_connect:875: sk 000000004dff667e iso_connect_cis:353: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da hci_get_route:1199: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da hci_conn_add:1005: hci0 dst 28:3d:c2:4a:7e:da iso_conn_add:140: hcon 000000007b65d182 conn 00000000daf8625e __iso_chan_add:214: conn 00000000daf8625e iso_connect_cfm:1700: hcon 000000007b65d182 bdaddr 28:3d:c2:4a:7e:da status 12 iso_conn_del:187: hcon 000000007b65d182 conn 00000000daf8625e, err 16 iso_sock_clear_timer:117: sock 000000004dff667e state 3 <Note: sk_state is BT_BOUND (3), so iso_connect_cis is still running at this point> iso_chan_del:153: sk 000000004dff667e, conn 00000000daf8625e, err 16 hci_conn_del:1151: hci0 hcon 000000007b65d182 handle 65535 hci_conn_unlink:1102: hci0: hcon 000000007b65d182 hci_chan_list_flush:2780: hcon 000000007b65d182 iso_sock_getsockopt:1376: sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e iso_sock_getsockopt:1376: sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e iso_sock_shutdown:1434:
    sock 00000000be9b69b7, sk 000000004dff667e, how 1 __iso_sock_close:632: sk 000000004dff667e state 5 socket 00000000be9b69b7 <Note: sk_state is BT_CONNECT (5), even though iso_chan_del sets BT_CLOSED (6). Only iso_connect_cis sets it to BT_CONNECT, so it must be that iso_chan_del occurred between iso_chan_add and end of iso_connect_cis.> BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 8000000006467067 P4D 8000000006467067 PUD 3f5f067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name:
    QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:__iso_sock_close (net/bluetooth/iso.c:664) bluetooth =============================================================== Trace with iso_conn_del before iso_chan_add in iso_connect_cis:
    =============================================================== iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 0000000093bc551f conn 00000000768ae504 hci_dev_put:1487: hci0 orig refcnt 21 hci_event_packet:7607: hci0: e ---truncated--- (CVE-2023-54164)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

AlmaLinux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1791800936 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：kunit: Fix potential null dereference in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

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

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

  - 已解決 Linux 核心中的下列弱點：devlink: fix xa_alloc_cyclic() error handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
    (CVE-2025-22017)

  - 已解決 Linux 核心中的下列弱點：drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端 Ubuntu 24.04 LTS 主機上安裝的一個套件受到 USN-8886-1 公告中所提及的多個弱點影響。

    在 Linux 核心中發現數個安全性問題。攻擊者可能會利用這些弱點入侵系統。此更新可更正下列子系統中的瑕疵：

    - NVDIMM (非易失性記憶體裝置) 驅動程式；

    - 交握 API；

    - ARM32 架構；

    - ARM64 架構 ;

    - MIPS 架構；

    - OpenRISC 架構；

    - PowerPC 架構；

    - S390 架構；

    - x86 架構;

    - 區塊層子系統；

    - 密碼編譯 API;

    - 英特爾 NPU 驅動程式;

    - Android 驅動程式 ;

    - Rados 區塊裝置 （RBD） 驅動程式;

    - 藍牙驅動程式;

    - 硬體亂數產生器核心；

    - TPM 裝置驅動程式；

    - CPU 頻率縮放架構;

    - 硬體加密裝置驅動程式；

    - DMA 引擎子系統;

    - FireWire 子系統；

    - 適用於 ARMv8-A(FFA) 的 Arm 韌體架構；

    - GPIO 子系統；

    - GPU 驅動程式；

    - HID 子系統 ;

    - 硬體監控驅動程式;

    - CoreSight 硬體追蹤驅動程式;

    - I2C 子系統；

    - IIO ADC 驅動程式；

    - IIO 子系統；

    - InfiniBand 驅動程式;

    - 輸入裝置核心驅動程式;

    - 輸入裝置 (滑鼠) 驅動程式；

    - IOMMU 子系統;

    - 多個裝置驅動程式；

    - 媒體驅動程式；

    - 多功能裝置驅動程式；

    - Fastrpc 驅動程式 ;

    - Amazon Nitro 安全模組驅動程式;

    - MMC 子系統；

    - MTD 區塊裝置驅動程式；

    - 乙太網路綁定驅動程式；

    - 網路驅動程式；

    - Mellanox 網路驅動程式；

    - Texas Instruments 網路驅動程式；

    - NTB 驅動程式；

    - NVME 驅動程式；

    - NVMEM（非揮發性記憶體）驅動程式;

    - Parport 驅動程式；

    - 針腳控制器子系統；

    - x86 平台驅動程式；

    - i.MX PM 網域；

    - 系統重置/關閉驅動程序;

    - PTP 時鐘架構；

    - 電壓和電流調節器驅動程式；

    - S/390 驅動程式 ;

    - SCSI 子系統 ;

    - SPI 子系統；

    - Realtek RTL8723BS SDIO 驅動程式；

    - VME 匯流排暫存驅動程式;

    - 熱驅動程式；

    - Thunderbolt 和 USB4 驅動程式 ;

    - TTY 驅動程式；

    - DesignWare USB2 驅動程式;

    - USB Gadget 驅動程式；

    - USB 主機控制器驅動程式；

    - USB Dual Role (OTG-ready) 控制器驅動程式；

    - USB 序列驅動程式；

    - USB Type-C Port Controller Manager 驅動程式；

    - vDPA 驅動程式;

    - Virtio Host (VHOST) 子系統;

    - Framebuffer 層；

    - Watchdog 驅動程式；

    - 9P 分散式檔案系統 ;

    - AFS 檔案系統;

    - 檔案系統基礎架構；

    - BTRFS 檔案系統 ;

    - Ceph 分散式檔案系統；

    - EROFS 檔案系統；

    - AexFAT 檔案系統；

    - F2FS 檔案系統；

    - FUSE (使用者空間中的檔案系統)；

    - 區塊裝置的日誌記錄層 (JBD2)；

    - 網路檔案系統 (NFS) 用戶端；

    - 網路檔案系統 (NFS) 伺服器程序；

    - NTFS3 檔案系統；

    - OCFS2 檔案系統；

    - Proc 檔案系統；

    - SMB 網路檔案系統 ;

    - 追蹤檔案系統 ;

    - UDF 檔案系統；

    - XFS 檔案系統；

    - 金鑰管理；

    - BPF 子系統；

    - 控制群組 (cgroup);

    - Glob 模式匹配庫;

    - MAC80211 子系統；

    - Mellanox 驅動程式；

    - 網路核心；

    - 網路通訊端；

    - IPv6 網路；

    - 藍牙子系統；

    - 無線網路 ；

    - IPv4 網路；

    - Netfilter；

    - 網路流量控制 ;

    - SCTP 通訊協定；

    - TCP 網路通訊協定；

    - XFRM 子系統；

    - RDMA 動詞 API；

    - io_uring 子系統;

    - IPC 子系統；

    - 稽核子系統；

    - Kernel CPU 控制基礎架構；

    - Perf 事件；

    - 核心 exit() 系統呼叫；

    - 核心 fork() 系統呼叫；

    - 排程器基礎架構；

    - 訊號處理機制；

    - Timer 子系統;

    - 追蹤基礎架構；

    - 可調整大小的雜湊表庫;

    - 記憶體管理；

    - 6LoWPAN網路協定;

    - 非同步傳輸模式 (ATM) 子系統；

    - B.A.T.M.A.N. 網狀通訊協定；

    - 乙太網路橋接器；

    - CAN 網路層

    - Ceph Core 程式庫；

    - Ethtool 驅動程式；

    - HSR 網路通訊協定；

    - IEEE802154.4 網路通訊協定；

    - IUCV 驅動程式；

    - KCM (核心連線多工器) 通訊端驅動程式 ;

    - IEEE 802.15.4 子系統；

    - 多重路徑 TCP;

    Open vSwitch；

    - 封包通訊端；

    - Phonet 通訊協定 ;

    - 高通IPC路由器（QRTR）;

    - RDS 通訊協定;

    - RxRPC 工作階段通訊端；

    - SMC 通訊端;

    - Sun RPC 通訊協定；

    - TIPC 通訊協定 ;

    - TLS 通訊協定；

    - Unix 網域通訊端;

    - VMware vSockets 驅動程式；

    - X.25 network layer;

    - eXpress 資料路徑；

    - AppArmor 安全性模組 ;

    - 完整性測量架構 (IMA) 框架；

    - SELinux 安全性模組；

    - ALSA 架構;

    - HD 音訊驅動程式；

    - QCOM ASoC 驅動程式；

    - 簡單的音頻多路復用器編解碼器驅動程序;

    - Texas InstrumentS Audio (ASoC/HDA) 驅動程式 ;

    - 適用於 Freescale CPU 的 SoC Audio 驅動程式 ;

    - Amlogic Meson SoC 驅動程式；

    - SOF 驅動程式；

    - NVIDIA Tegra ASoC 驅動程式;

    - USB 音效裝置；

    - 性能工具;

    - KVM 子系統;（CVE-2025-37807 ， ， ， CVE-2026-43022， CVE-2026-46321CVE-2026-53267CVE-2026-53160CVE-2026-53161CVE-2026-53136CVE-2026-53137CVE-2026-52994CVE-2026-53143CVE-2026-53138CVE-2026-53146CVE-2026-53147CVE-2026-53149CVE-2026-53156CVE-2026-53157CVE-2026-52947CVE-2026-53189CVE-2026-53184CVE-2026-53194CVE-2026-53195CVE-2026-53199CVE-2026-53202CVE-2026-53205CVE-2026-52943CVE-2026-53223CVE-2026-53209CVE-2026-53229CVE-2026-53253CVE-2026-53255CVE-2026-53268CVE-2026-53272CVE-2026-52942CVE-2026-53330CVE-2026-53329CVE-2026-53389CVE-2026-53388CVE-2026-53390CVE-2026-53387CVE-2026-53383CVE-2026-53381CVE-2026-53391CVE-2026-53366CVE-2026-53365CVE-2026-53362CVE-2026-53392CVE-2026-53356CVE-2026-52935CVE-2026-53397CVE-2026-63794CVE-2026-53402CVE-2026-63802CVE-2026-53401CVE-2026-63803CVE-2026-63805CVE-2026-46322CVE-2026-52923CVE-2026-63806CVE-2026-52917CVE-2026-52927CVE-2026-52929CVE-2026-53400CVE-2026-23265、、、 CVE-2026-64005CVE-2026-63869CVE-2026-63867CVE-2026-63870CVE-2026-63875CVE-2026-63879CVE-2026-63881CVE-2026-63884CVE-2026-63833CVE-2026-63909CVE-2026-63889CVE-2026-63913CVE-2026-63920CVE-2026-63925CVE-2026-63927CVE-2026-63930CVE-2026-63827CVE-2026-63954CVE-2026-63942CVE-2026-63968CVE-2026-63970CVE-2026-63971CVE-2026-63985CVE-2026-64002CVE-2026-63824CVE-2026-64004CVE-2026-64003CVE-2026-64009CVE-2026-64017CVE-2026-64023CVE-2026-64239CVE-2026-64222CVE-2026-64210CVE-2026-64242CVE-2026-64189CVE-2026-64188CVE-2026-64123CVE-2026-64243CVE-2026-64095CVE-2026-64036CVE-2026-64026CVE-2026-64245CVE-2026-63823CVE-2026-63817CVE-2026-64277CVE-2026-64272CVE-2026-64276CVE-2026-64266CVE-2026-64270CVE-2026-64271CVE-2026-64274CVE-2026-64279CVE-2026-63819CVE-2026-64273CVE-2026-63816CVE-2026-64246CVE-2026-63814CVE-2026-63812CVE-2026-63809、 、 、 、 CVE-2026-64418CVE-2026-64322CVE-2026-64318CVE-2026-64324CVE-2026-64323CVE-2026-64333CVE-2026-64368CVE-2026-64372CVE-2026-64374CVE-2026-64375CVE-2026-64317CVE-2026-64379CVE-2026-64378CVE-2026-64380CVE-2026-64388CVE-2026-64389CVE-2026-64395CVE-2026-64398CVE-2026-64312CVE-2026-64402CVE-2026-64401CVE-2026-64403CVE-2026-64411CVE-2026-64412CVE-2026-64413CVE-2026-64442CVE-2026-64440CVE-2026-64443CVE-2026-64436CVE-2026-64435CVE-2026-64432CVE-2026-64444CVE-2026-64430CVE-2026-64423CVE-2026-64422CVE-2026-64448CVE-2026-64420CVE-2026-64304CVE-2026-64299CVE-2026-64298CVE-2026-64532CVE-2026-64463CVE-2026-64468CVE-2026-64469CVE-2026-64456CVE-2026-64496CVE-2026-64533CVE-2026-64481CVE-2026-64449CVE-2026-64452CVE-2026-64524CVE-2026-64296CVE-2026-64287CVE-2026-64286CVE-2026-64283、 、 、 、 CVE-2026-68104CVE-2026-64563CVE-2026-64560CVE-2026-64568CVE-2026-64567CVE-2026-64570CVE-2026-64574CVE-2026-64576CVE-2026-64577CVE-2026-64578CVE-2026-64556CVE-2026-64581CVE-2026-64580CVE-2026-64582CVE-2026-64583CVE-2026-64584CVE-2026-64585CVE-2026-64599CVE-2026-64550CVE-2026-68091CVE-2026-64600CVE-2026-68096CVE-2026-68097CVE-2026-68098CVE-2026-68100CVE-2026-68129CVE-2026-68125CVE-2026-68131CVE-2026-68121CVE-2026-68119CVE-2026-68118CVE-2026-68140CVE-2026-68116CVE-2026-68108CVE-2026-68107CVE-2026-68141CVE-2026-68106CVE-2026-64547CVE-2026-64546CVE-2026-64545CVE-2026-68179CVE-2026-68148CVE-2026-68149CVE-2026-68153CVE-2026-68145CVE-2026-68157CVE-2026-68189CVE-2026-68155CVE-2026-68142CVE-2026-68143CVE-2026-68178CVE-2026-64543CVE-2026-64540CVE-2026-64539CVE-2026-64536、 、 、 、 CVE-2026-68329CVE-2026-68253CVE-2026-68245CVE-2026-68258CVE-2026-68255CVE-2026-68260CVE-2026-68262CVE-2026-68263CVE-2026-68266CVE-2026-68273CVE-2026-68236CVE-2026-68287CVE-2026-68284CVE-2026-68290CVE-2026-68293CVE-2026-68294CVE-2026-68297CVE-2026-68299CVE-2026-68222CVE-2026-68315CVE-2026-68314CVE-2026-68320CVE-2026-68322CVE-2026-68323CVE-2026-68326CVE-2026-68371CVE-2026-68370CVE-2026-68373CVE-2026-68354CVE-2026-68353CVE-2026-68352CVE-2026-68376CVE-2026-68348CVE-2026-68340CVE-2026-68338CVE-2026-68377CVE-2026-68335CVE-2026-68219CVE-2026-68216CVE-2026-68204CVE-2026-68402CVE-2026-68392CVE-2026-68397CVE-2026-68398CVE-2026-68391CVE-2026-68400CVE-2026-68404CVE-2026-68399CVE-2026-68383CVE-2026-68389CVE-2026-68401CVE-2026-68202CVE-2026-68199CVE-2026-68196CVE-2026-68192、 、 、 、 CVE-2026-72049CVE-2026-68446CVE-2026-68445CVE-2026-68451CVE-2026-68447CVE-2026-68452CVE-2026-68453CVE-2026-68454CVE-2026-68466CVE-2026-68467CVE-2026-68442CVE-2026-68474CVE-2026-68471CVE-2026-68479CVE-2026-72005CVE-2026-72009CVE-2026-72012CVE-2026-72019CVE-2026-68433CVE-2026-72024CVE-2026-72021CVE-2026-72029CVE-2026-72035CVE-2026-72036CVE-2026-72045CVE-2026-72067CVE-2026-72066CVE-2026-72072CVE-2026-72061CVE-2026-72057CVE-2026-72055CVE-2026-72089CVE-2026-72054CVE-2026-72053CVE-2026-72052CVE-2026-72099CVE-2026-72051CVE-2026-68432CVE-2026-68425CVE-2026-68419CVE-2026-72116CVE-2026-72108CVE-2026-72109CVE-2026-72110CVE-2026-72107CVE-2026-72114CVE-2026-72117CVE-2026-72113CVE-2026-72102CVE-2026-72105CVE-2026-72115CVE-2026-68417CVE-2026-68414CVE-2026-68409CVE-2026-68408、 、 、 、 CVE-2026-72233CVE-2026-72146CVE-2026-72144CVE-2026-72149CVE-2026-72148CVE-2026-72157CVE-2026-72160CVE-2026-72162CVE-2026-72164CVE-2026-72165CVE-2026-72136CVE-2026-72171CVE-2026-72170CVE-2026-72172CVE-2026-72175CVE-2026-72181CVE-2026-72195CVE-2026-72196CVE-2026-72135CVE-2026-72213CVE-2026-72197CVE-2026-72225CVE-2026-72227CVE-2026-72231CVE-2026-72232CVE-2026-72254CVE-2026-72253CVE-2026-72261CVE-2026-72252CVE-2026-72250CVE-2026-72247CVE-2026-72262CVE-2026-72244CVE-2026-72243CVE-2026-72242CVE-2026-72282CVE-2026-72235CVE-2026-72133CVE-2026-72123CVE-2026-72122CVE-2026-72330CVE-2026-72301CVE-2026-72302CVE-2026-72304CVE-2026-72298CVE-2026-72312CVE-2026-72334CVE-2026-72310CVE-2026-72284CVE-2026-72297CVE-2026-72314CVE-2026-72121CVE-2026-72120CVE-2026-72119CVE-2026-72118、 、 、 、 CVE-2026-72435CVE-2026-72373CVE-2026-72371CVE-2026-72375CVE-2026-72374CVE-2026-72378CVE-2026-72382CVE-2026-72389CVE-2026-72390CVE-2026-72397CVE-2026-72369CVE-2026-72404CVE-2026-72400CVE-2026-72405CVE-2026-72406CVE-2026-72409CVE-2026-72410CVE-2026-72416CVE-2026-72352CVE-2026-72419CVE-2026-72418CVE-2026-72420CVE-2026-72423CVE-2026-72425CVE-2026-72427CVE-2026-72469CVE-2026-72464CVE-2026-72470CVE-2026-72460CVE-2026-72459CVE-2026-72450CVE-2026-72476CVE-2026-72449CVE-2026-72444CVE-2026-72440CVE-2026-72478CVE-2026-72438CVE-2026-72350CVE-2026-72347CVE-2026-72343CVE-2026-74270CVE-2026-72492CVE-2026-72502CVE-2026-74256CVE-2026-72485CVE-2026-74258CVE-2026-74281CVE-2026-74257CVE-2026-72480CVE-2026-72483CVE-2026-74262CVE-2026-72342CVE-2026-72340CVE-2026-72338CVE-2026-72335、 、 、 、 CVE-2026-74378CVE-2026-74300CVE-2026-74297CVE-2026-74313CVE-2026-74312CVE-2026-74314CVE-2026-74317CVE-2026-74321CVE-2026-74330CVE-2026-74334CVE-2026-74296CVE-2026-74340CVE-2026-74338CVE-2026-74341CVE-2026-74344CVE-2026-74347CVE-2026-74349CVE-2026-74356CVE-2026-74295CVE-2026-74363CVE-2026-74359CVE-2026-74365CVE-2026-74374CVE-2026-74375CVE-2026-74377CVE-2026-74444CVE-2026-74443CVE-2026-74446CVE-2026-74438CVE-2026-74397CVE-2026-74390CVE-2026-74450CVE-2026-74388CVE-2026-74387CVE-2026-74385CVE-2026-74453CVE-2026-74380CVE-2026-74294CVE-2026-74293CVE-2026-74292CVE-2026-74481CVE-2026-74465CVE-2026-74467CVE-2026-74469CVE-2026-74461CVE-2026-74471CVE-2026-74482CVE-2026-74470CVE-2026-74454CVE-2026-74456CVE-2026-74479CVE-2026-74289CVE-2026-74288CVE-2026-74283CVE-2026-74282、 、 、 、 CVE-2026-74557CVE-2026-74512CVE-2026-74510CVE-2026-74516CVE-2026-74515CVE-2026-74518CVE-2026-74519CVE-2026-74522CVE-2026-74523CVE-2026-74527CVE-2026-74509CVE-2026-74531CVE-2026-74530CVE-2026-74533CVE-2026-74534CVE-2026-74535CVE-2026-74536CVE-2026-74537CVE-2026-74508CVE-2026-74544CVE-2026-74540CVE-2026-74548CVE-2026-74549CVE-2026-74550CVE-2026-74551CVE-2026-74579CVE-2026-74578CVE-2026-74580CVE-2026-74575CVE-2026-74574CVE-2026-74572CVE-2026-74581CVE-2026-74567CVE-2026-74565CVE-2026-74564CVE-2026-74582CVE-2026-74563CVE-2026-74507CVE-2026-74497CVE-2026-74496CVE-2026-74595CVE-2026-74587CVE-2026-74588CVE-2026-74589CVE-2026-74586CVE-2026-74592CVE-2026-74597CVE-2026-74590CVE-2026-74583CVE-2026-74584CVE-2026-74594CVE-2026-74492CVE-2026-74490CVE-2026-74488CVE-2026-74485、 、 、 、 CVE-2026-74649CVE-2026-74611CVE-2026-74610CVE-2026-74613CVE-2026-74612CVE-2026-74614CVE-2026-74615CVE-2026-74616CVE-2026-74621CVE-2026-74624CVE-2026-74609CVE-2026-74626CVE-2026-74625CVE-2026-74628CVE-2026-74630CVE-2026-74631CVE-2026-74632CVE-2026-74634CVE-2026-74608CVE-2026-74637CVE-2026-74635CVE-2026-74641CVE-2026-74646CVE-2026-74647CVE-2026-74648CVE-2026-74668CVE-2026-74667CVE-2026-74669CVE-2026-74666CVE-2026-74663CVE-2026-74662CVE-2026-74670CVE-2026-74661CVE-2026-74660CVE-2026-74656CVE-2026-74675CVE-2026-74651CVE-2026-74607CVE-2026-74606CVE-2026-74605CVE-2026-74696CVE-2026-74688CVE-2026-74689CVE-2026-74690CVE-2026-74687CVE-2026-74692CVE-2026-74697CVE-2026-74691CVE-2026-74678CVE-2026-74684CVE-2026-74695CVE-2026-74604CVE-2026-74603CVE-2026-74601CVE-2026-74598、 、 、 、 CVE-2026-80540CVE-2026-74720CVE-2026-74717CVE-2026-74724CVE-2026-74723CVE-2026-74725CVE-2026-74726CVE-2026-74730CVE-2026-74733CVE-2026-74736CVE-2026-74715CVE-2026-74739CVE-2026-74737CVE-2026-74743CVE-2026-74744CVE-2026-74746CVE-2026-74747CVE-2026-74748CVE-2026-74714CVE-2026-80521CVE-2026-74752CVE-2026-80526CVE-2026-80527CVE-2026-80528CVE-2026-80536CVE-2026-80554CVE-2026-80553CVE-2026-80555CVE-2026-80552CVE-2026-80551CVE-2026-80550CVE-2026-80556CVE-2026-80549CVE-2026-80548CVE-2026-80547CVE-2026-80557CVE-2026-80541CVE-2026-74713CVE-2026-74711CVE-2026-74710CVE-2026-80574CVE-2026-80561CVE-2026-80565CVE-2026-80568CVE-2026-80560CVE-2026-80570CVE-2026-80576CVE-2026-80569CVE-2026-80558CVE-2026-80559CVE-2026-80572CVE-2026-74705CVE-2026-74704CVE-2026-74701CVE-2026-74700CVE-2026-80578、CVE-2026-80579、、CVE-2026-80580、CVE-2026-80583CVE-2026-80901CVE-2026-97509CVE-2026-80589CVE-2026-80586CVE-2026-80721CVE-2026-80584CVE-2026-80585CVE-2026-80587）

Tenable 已直接從 Ubuntu 安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
335510	Linux Distros 未修補弱點：CVE-2026-72438	Nessus	Misc.	2026/8/15	2026/11/7	high
365209	Amazon Linux 2023：bpftool6.12、kernel6.12、kernel6.12-devel （ALAS2023-2026-3193）	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/11/2	medium
365767	Ubuntu 26.04 LTS : Linux 核心弱點 (USN-8887-1)	Nessus	Ubuntu Local Security Checks	2026/10/14	2026/10/14	medium
364137	Oracle Linux 10 / 9：Unbreakable Enterprise 核心 (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
365768	Ubuntu 26.04 LTS：Linux 核心 (Azure) 弱點 (USN-8888-1)	Nessus	Ubuntu Local Security Checks	2026/10/14	2026/10/14	medium
364682	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc多個漏洞（ALMALINUX9.6：CLSA-2026：1791800936）	Nessus	Rocky Linux Local Security Checks	2026/10/12	2026/10/13	high
351155	Debian dsa-6528 ： ata-modules-6.12.111+deb13-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/9/29	2026/9/29	high
360912	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1789898700）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
362907	Debian dla-4817 ： ata-modules-6.12.107+deb12-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/10/4	2026/10/4	high
365258	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/29	high
364689	AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1791800936）	Nessus	Alma Linux Local Security Checks	2026/10/12	2026/10/13	high
365457	Ubuntu 24.04 LTS：Linux 核心 (NVIDIA Tegra) 弱點 (USN-8886-1)	Nessus	Ubuntu Local Security Checks	2026/10/13	2026/10/13	high
365463	Ubuntu 26.04 LTS：Linux 核心 (OEM) 弱點 (USN-8889-1)	Nessus	Ubuntu Local Security Checks	2026/10/13	2026/10/13	medium

偵測

搜尋 Plugin

high

medium

medium

high

medium

high

high

high

high

high

high

high

medium