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

  - igc不會使 LED 設定錯誤的 igc_probe() 失敗當 igc_led_setup() 失敗時由於未呼叫 unregister_netdev()igc_probe() 也會失敗並在 free_netdev() 中觸發核心錯誤。 [1] 可使用錯誤插入架構測試此行為尤其是使用 failslab 功能。 [2] 由於 LED 支援並非強制要求請將 LED 設定失敗視為非嚴重並繼續探查並顯示警告訊息進而避免核心錯誤。 [1] net/core/dev.c:12047! 的核心錯誤Oops無效 opcode0000 [#1] SMP NOPTI CPU0 UID0 PID937 Commrepro-igc-led-e 未受污染的 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(vulnerable ) 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP 0010:free_netdev+0x278/0x2b0 [...] 呼叫追踪 <TASK> igc_probe+0x370/0x910 local_pci_probe+0x3a/0x80 pci_device_probe+0xd1/0x200 [...] [2] #!/bin/bash -ex FAILSLAB_PATH=/sys/kernel/debug/failslab/ DEVICE=0000:00 05.0 START_ADDR=$(grep igc_led_setup /proc/kallsyms \ | awk '{printf(0x%s, $1)}') END_ADDR=$(printf 0x%x $((START_ADDR + 0x100))) echo $START_ADDR > $FAILSLAB_PATH/require-start echo $END_ADDR > $FAILSLAB_PATH/require-end echo 1 > $FAILSLAB_PATH/times echo 100 > $FAILSLAB_PATH/probability echo N > $FAILSLAB_PATH/ignore-gfp-wait echo $DEVICE > /sys/bus/pci/drivers/igc/bind (CVE-2025-39956)

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

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

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：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)

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

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

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：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)

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

因此，會受到 ALAS2023-2025-1254 公告中所提及的多個弱點影響。

    在 Linux 核心中，下列弱點已解決：

    io_uring/kbuf一律使用 READ_ONCE() 來讀取 ring 提供的緩衝區長度 (CVE-2025-39816)

    在 Linux 核心中，下列弱點已解決：

    cryptoaf_alg - 在 af_alg_sendmsg 中提早將合併設為零 (CVE-2025-39931)

    在 Linux 核心中，下列弱點已解決：

    dm-stripe修正可能的整數溢位 (CVE-2025-39940)

    在 Linux 核心中，下列弱點已解決：

    tls確保在標頭是假的情況下中止資料流 (CVE-2025-39946)

    在 Linux 核心中，下列弱點已解決：

    net/mlx5e針對裝置取消系結強化上傳連結 netdev 存取 (CVE-2025-39947)

    在 Linux 核心中，下列弱點已解決：

    cgroup將 cgroup_destroy_wq 分割為 3 個工作佇列 (CVE-2025-39953)

    在 Linux 核心中，下列弱點已解決：

    tcp清除 tcp_disconnect() 中的 tcp_sk(sk)->fastopen_rsk。 (CVE-2025-39955)

    在 Linux 核心中，下列弱點已解決：

    igc不要使發生 LED 設定錯誤的 igc_probe() 失敗 (CVE-2025-39956)

    在 Linux 核心中，下列弱點已解決：

    iommu/amd/pgtbl修正增加頁面表格層級時可能發生的爭用 (CVE-2025-39961)

    在 Linux 核心中，下列弱點已解決：

    io_uring修正 io_link_skb 中不正確的 io_kiocb 參照 (CVE-2025-39963)

    在 Linux 核心中，下列弱點已解決：

    cryptoaf_alg - 不允許 af_alg_sendmsg 中的並行寫入 (CVE-2025-39964)

    在 Linux 核心中，下列弱點已解決：

    xfrmxfrm_alloc_spi 不應使用 0 作為 SPI (CVE-2025-39965)

    在 Linux 核心中，下列弱點已解決：

    fbcon修正 fbcon_do_set_font 中的整數溢位 (CVE-2025-39967)

    在 Linux 核心中，下列弱點已解決：

    smb用戶端修正 smb2_compound_op() 中錯誤的索引參照 (CVE-2025-39975)

    在 Linux 核心中，下列弱點已解決：

    futex防止 requeue-PI 期間發生釋放後使用 (CVE-2025-39977)

    在 Linux 核心中，下列弱點已解決：

    nexthop當 nexthop 位於群組中時禁止 FDB 狀態變更 (CVE-2025-39980)

    在 Linux 核心中，下列弱點已解決：

    nettun在 XDP 處理程序後更新 napi->skb (CVE-2025-39984)

    在 Linux 核心中，下列弱點已解決：

    bpf檢查 get_helper_proto 中的 helper 函式是否有效 (CVE-2025-39990)

    在 Linux 核心中，下列弱點已解決：

    mmswap在 VMA 上操作前檢查穩定的位址空間 (CVE-2025-39992)

    在 Linux 核心中，下列弱點已解決：

    scsi目標target_core_configfs新增長度檢查以避免緩衝區溢位 (CVE-2025-39998)

    在 Linux 核心中，下列弱點已解決：

    mm/hugetlb修正作品集在刪除時仍會對應 (CVE-2025-40006)

    在 Linux 核心中，下列弱點已解決：

    fs/proc/task_mmu檢查 NULL 的 p->vec_buf (CVE-2025-40009)

    在 Linux 核心中，下列弱點已解決：

    ipvs在 netns 清理期間延遲 ip_vs_ftp 取消註冊 (CVE-2025-40018)

    在 Linux 核心中，下列弱點已解決：

    tracing dynevent新增 dynevent 缺少的鎖定檢查 (CVE-2025-40021)

    在 Linux 核心中，下列弱點已解決：

    vhost取得結構 vhost_task 中工作的參照。 (CVE-2025-40024)

    在 Linux 核心中，下列弱點已解決：

    pinctrl檢查 pinmux_ops::get_function_name() 的傳回值 (CVE-2025-40030)

    在 Linux 核心中，下列弱點已解決：

    輸入uinput - 將 uinput_ff_upload_compat 零初始化以避免資訊洩漏 (CVE-2025-40035)

    在 Linux 核心中，下列弱點已解決：

    fsudf修正lengthAllocDescs 處理中的 OOB 讀取 (CVE-2025-40044)

    在 Linux 核心中，下列弱點已解決：

    io_uring/waitid一律刪除 io_waitid_wait() 中的等待佇列項目 (CVE-2025-40047)

    在 Linux 核心中，下列弱點已解決：

    uio_hv_generic讓使用者空間處理中斷遮罩 (CVE-2025-40048)

    在 Linux 核心中，下列弱點已解決：

    Squashfs修正 squashfs_get_parent 中的 uninit-value (CVE-2025-40049)

    在 Linux 核心中，下列弱點已解決：

    smb用戶端修正非線形記憶體中的密碼編譯緩衝區 (CVE-2025-40052)

    在 Linux 核心中，下列弱點已解決：

    ptp在 max_vclocks 上新增上限 (CVE-2025-40057)

    在 Linux 核心中，下列弱點已解決：

    iommu/vt-d如果頁面不連貫則不允許已變更的追踪 (CVE-2025-40058)

    在 Linux 核心中，下列弱點已解決：

    fs/ntfs3如果 $BITMAP 為空白但存在區塊則拒絕索引配置 (CVE-2025-40067)

    在 Linux 核心中，下列弱點已解決：

    fsntfs3修正 run_unpack() 中的整數溢位 (CVE-2025-40068)

    在 Linux 核心中，下列弱點已解決：

    pps修正註冊裝置失敗時pps_register_cdev 中的警告 (CVE-2025-40070)

    在 Linux 核心中，下列弱點已解決：

    bpf明確檢查對 bpf_sock_addr 的存取 (CVE-2025-40078)

    在 Linux 核心中，下列弱點已解決：

    nbd將通訊端限制為 TCP 和 UDP (CVE-2025-40080)

    在 Linux 核心中，下列弱點已解決：

    perfarm_spe防止 PERF_IDX2OFF() 中的溢位 (CVE-2025-40081)

    在 Linux 核心中，下列弱點已解決：

    cryptorng - 確保 set_ent 一律存在 (CVE-2025-40109)

    在 Linux 核心中，下列弱點已解決：

    scsimpt3sas使用 ioc_info() 修正傳輸連接埠移除時發生的損毀 (CVE-2025-40115)

    在 Linux 核心中，下列弱點已解決：

    bpf針對 tailcall 相容性強制執行 expected_attach_type (CVE-2025-40123)

    在 Linux 核心中，下列弱點已解決：

    blk-mq在 blk_mq_unregister_hctx 中刪除前檢查 kobject state_in_sysfs (CVE-2025-40125)

    在 Linux 核心中，下列弱點已解決：

    sunrpc修正零長度總和檢查碼上的 null 指標解除參照 (CVE-2025-40129)

    在 Linux 核心中，下列弱點已解決：

    dm修正 __dm_suspend() 中的 NULL 指標解除參照 (CVE-2025-40134)

    在 Linux 核心中，下列弱點已解決：

    mmhugetlbmprotect to 大型記憶體區域時避免軟鎖定 (CVE-2025-40153)

    在 Linux 核心中，下列弱點已解決：

    bpf拒絕 ALU 作業的負位移 (CVE-2025-40169)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
270204	Linux Distros 未修補的弱點：CVE-2025-39956	Nessus	Misc.	2025/10/13	2026/7/31	medium
352220	AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1787305050）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/9/30	high
352240	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1787305050）	Nessus	Rocky Linux Local Security Checks	2026/9/30	2026/9/30	high
271737	Amazon Linux 2023bpftool6.12、kernel6.12、kernel6.12-devel (ALAS2023-2025-1254)	Nessus	Amazon Linux Local Security Checks	2025/10/28	2026/9/18	high

偵測

搜尋 Plugin

medium

high

high

high