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

  - VMCI在呼叫 get_user_pages_fast() 後檢查 context->notify_page 以避免 GPF。在 vmci_host_setup_notify() 中對 get_user_pages_fast() 的呼叫可傳回 NULL context->notify_page造成 GPF。避免 GPF 檢查 context->notify_page == NULL 若為 則傳回錯誤。一般保護錯誤可能是針對非正式位址 0xe0009d1000000060 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN 可能是 wild-memory-access 範圍 [0x0005088000000300- 0x0005088000000307] CPU2 PID 26180 通訊retaintedNot_3410.24。 -rc4 #1 硬體名稱Red Hat KVM、BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP
    0010vmci_ctx_check_signal_notify+0x91/0xe0 呼叫追踪 <TASK> vmci_host_unlocked_ioctl+0x362/0x1f40
    __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2023-53259)

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

遠端主機上安裝的核心版本早於 5.15.102-61.139。因此，會受到 ALAS2KERNEL-5.15-2023-015 公告中所提及的多個弱點影響。

    Linux 核心的 KVM: nVMX 中存在迴歸問題，會引起推測執行攻擊。
    因為 KVM (L0) 向 L1 通告 eIBRS 支援，L1 認為在執行 L2 後其不需要 retpolines 或 IBPB，所以 L2 可以對 L1 發動 Spectre v2 攻擊。在 L2 具有程式碼執行權限的攻擊者可在主機的間接分支上執行程式碼。建議升級爲 Kernel 6.2 或之前的 commit 2e7eab81425a (CVE-2022-2196)

    據發現，在某些 AMD CPU 上，RAS (在某些 AMD 文件中亦稱為 RAP - Return Address Predictor，在 Intel 術語中稱為 RSB - Return Stack Buffer) 會在非閒置執行緒之間動態分割。這可讓攻擊者控制相鄰執行緒上的推測執行。(CVE-2022-27672)

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

    netfilternft_tproxy限制為 prerouting 勾點 (CVE-2022-50001)

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

    drm修正因 drmm_mode_config_init() 引起的潛在 null-ptr-deref (CVE-2022-50556)

    偵測到一些可遭惡意利用的小工具，這些小工具可透過側通道 (如 MDS) 以及針對 spectre-v1 的 usercopy 函式強化不足，來洩漏私密記憶體。(CVE-2023-0458)

    由於初始化期間的類型混淆問題，Linux 核心中的 tun 和 tap 通訊端將其通訊端 UID 硬式編碼為 0 (即 root)。雖然這通常是正確的，因為 TUN/TAP 裝置需要 CAP_NET_ADMIN，但也存在例外情況。通訊端 UID 可用於網路篩选和路由，因此可能導致 TUN/TAP 通訊端管理方式錯誤，進而可能繞過以 UID 為基礎的網路篩選器。(CVE-2023-1076)

    核心：pick_next_rt_entity() 中存在類型混淆弱點，此弱點可導致記憶體損毀。(CVE-2023-1077)

    上游錯誤報告對此問題的描述如下：

    在 Linux 核心的可靠資料包通訊端 (RDS) 通訊協定實作中發現一個瑕疵。rds_rm_zerocopy_callback() 在清單標頭上使用 list_entry()，可造成類型混淆。本機使用者可透過 rds_message_put() 觸發此問題。類型混淆導致 `struct rds_zcopy_info *info` 實際上指向可能由本機使用者控制的其他內容。目前已知此問題的觸發方式，觸發後可造成超出邊界存取和鎖定損毀。(CVE-2023-1078)

    Linux 核心流量控制索引篩選器 (tcindex) 中的釋放後使用弱點可觸發特權提升攻擊。不完整的雜湊區域可在封包遊走時更新，這將在使用損毀的 tcf_ext 呼叫「tcf_exts_exec()」時造成釋放後使用。本機攻擊者可利用此弱點將特權提升為根權限。此問題會影響 Linux 核心：從 4.14 開始的版本，直至 git 認可 ee059170b1f7e94e55fa6cadee544e176a6e59c2 之前。(CVE-2023-1281)

    Linux 核心流量控制索引篩選器 (tcindex) 中的釋放後使用弱點可被利用來提升本機權限。tcindex_delete 函式在刪除基礎結構時未正確停用篩選器，從而會在稍後導致重複釋放該結構。本機攻擊者可利用此弱點來將特權提升為根權限。我們建議使用者升級過去的認可 8c710f75256bb3cf05ac7b1672c82b92c43f3d28。(CVE-2023-1829)

    Linux 核心 io_uring 系統中包含釋放後使用弱點，攻擊者可藉此來提升本機權限。

    io_file_get_fixed 函式缺少 ctx->uring_lock，這可能會因修正檔案取消註冊的爭用情形而導致釋放後使用弱點。

    我們建議升級為之前的 commit da24142b1ef9fd5d36b76e36bab328a5b27523e8。(CVE-2023-1872)

    啟用純文字 IBRS (非增強型 IBRS) 時，spectre_v2_user_select_mitigation() 中的邏輯會判定不需要 STIBP。IBRS 位元可暗中防止跨執行緒分支目標插入。但是，使用舊版 IBRS 時，由於效能原因，IBRS 位元會在傳回至使用者空間時遭到清除，這會使使用者空間執行緒容易受到 STIBP 防範的跨執行緒分支目標插入攻擊。(CVE-2023-1998)

    - 在低於 6.1.13 版的 Linux 核心中，重新命名裝置期間發生配置失敗 (用於在新位置下登記 sysctl 表格) 後，net/mpls/af_mpls.c 中會發生雙重釋放。(CVE-2023-26545)

    在 Linux 核心中 fs/hfsplus/super.c 的 hfsplus_put_super 中發現釋放後使用缺陷。本機使用者可利用此缺陷造成拒絕服務。(CVE-2023-2985)

    在 6.2.3 版之前的 Linux 核心中，發現 lib/kobject.c 存在問題。攻擊者可藉由 root 存取權觸發爭用情形，進而導致 fill_kobj_path 超出邊界寫入。(CVE-2023-45863)

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

    aio：修復分支解除參照 Null 指標後的 mremap (CVE-2023-52646)

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

    netopenvswitch修正 ovs_meter_cmd_set() 中的潛在記憶體洩漏 (CVE-2023-52702)

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

    sched/psi：修正 ep_remove_wait_queue() 中的釋放後使用弱點 (CVE-2023-52707)

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

    bpf, sockmap：不讓 sock_map_{close,destroy,unhash} 自行呼叫 (CVE-2023-52735)

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

    修正 __free_pages 中的 racy 檢查所造成的頁面損毀 (CVE-2023-52739)

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

    cifs：修正 rdata->read_into_pages() 中的釋放後使用 (CVE-2023-52741)

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

    xfrm/compat：阻止 xfrm_xlate32_attr() 中潛在的 spectre v1 小工具 (CVE-2023-52746)

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

    vfio/type1防止透過 exec() 發生 locked_vm 的反向溢位 (CVE-2023-53171)

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

    USBuhci透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53197)

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

    netfilterx_tables修正建立新 netns 時錯誤路徑上的 percpu 計數器區塊洩漏 (CVE-2023-53200)

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

    PMdomains使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53202)

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

    ext4修正 ext4_feat_ktype 的函式原型不相符 (CVE-2023-53224)

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

    watchdog修正 watchdog_cdev_register 中的 kmemleak (CVE-2023-53234)

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

    firmwaredmi-sysfs修正 dmi_sysfs_register_handle 中的 null-ptr-deref (CVE-2023-53250)

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

    VMCI在呼叫 get_user_pages_fast() 之後檢查 context->notify_page 以避免 GPF (CVE-2023-53259)

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

    miscvmw_balloon透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53279)

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

    udf不針對內嵌檔案寫入失敗更新檔案長度 (CVE-2023-53295)

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

    rbd避免當 rbd_dev_create() 失敗時在 do_rbd_add() 中發生釋放後使用 (CVE-2023-53307)

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

    USB修正因使用 debugfs_lookup() 而發生的記憶體洩漏 (CVE-2023-53359)

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

    cryptoseqiv - 正確處理 EBUSY (CVE-2023-53373)

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

    driversbasedd使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53390)

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

    trace/blktrace透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53408)

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

    drivers基礎元件修正因使用 debugfs_lookup() 發生的記憶體洩漏問題 (CVE-2023-53409)

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

    PMEM修正使用 debugfs_lookup() 時發生的記憶體洩漏問題 (CVE-2023-53411)

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

    objtool修正 create_static_call_sections() 中的記憶體洩漏 (CVE-2023-53423)

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

    cifs修正損毀 MR 清單時的警告和 UAF (CVE-2023-53427)

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

    ipv6在 nexthop 計算中新增所有同級的 lwtunnel 封裝大小 (CVE-2023-53477)

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

    iommu修正 iommu_group_alloc() 中的錯誤回溯 (CVE-2023-53482)

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

    cryptoxts - 正確處理 EBUSY (CVE-2023-53494)

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

    udf請勿合併非常長的範圍 (CVE-2023-53506)

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

    sctp在 sctp_stream_priorities 中新增 refcnt 以避免巢狀迴圈 (CVE-2023-53590)

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

    驅動程式核心修正 device_add() 中的資源洩漏 (CVE-2023-53594)

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

    irqchip修正 platform_irqchip_probe 中的 refcount 洩漏 (CVE-2023-53610)

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

    udf偵測連結至目錄階層的系統 inode (CVE-2023-53695)

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

    ring-buffer處理 rb_move_tail 和 rb_check_pages 之間的爭用 (CVE-2023-53709)

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

    blk-iocost修正 calc_lcoefs() 中的除以 0 錯誤 (CVE-2023-53783)

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

    迴圈指派前的 loop_set_status_from_info() 檢查 (CVE-2023-53820)

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

    usbearlyxhci-dbc修正潛在的越界記憶體存取 (CVE-2023-53840)

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

    KVM如果 coalesced MMIO 取消註冊失敗則破壞目標裝置 (CVE-2023-54024)

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

    cryptoesiv - 正確處理 EBUSY (CVE-2023-54046)

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

    ledsled-core修正 of_led_get() 中的 refcount 洩漏 (CVE-2023-54190)

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

    tty修正 tty_driver_lookup_tty() 中的越界存取 (CVE-2023-54198)

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

    netfilterebtables修正表格 blob 釋放後使用 (CVE-2023-54243)

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

    cifsMR 配置失敗時修正遺失的破壞 smbd 連線 (CVE-2023-54260)

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

    ext4拒絕在卸載時建立 ea 區塊 (CVE-2023-54305)

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

    nettls避免在 tx_lock 上懸置工作 (CVE-2023-54306)

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

    dm flakey不損毀零頁面 (CVE-2023-54317)

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

    驅動程式核心修正 device_add() 中潛在的 null-ptr-deref (CVE-2023-54321)

    核心：ctnetlink_create_conntrack() 中的參照計數洩漏問題 (CVE-2023-7192)

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

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

CentOS Linux 8 主機安裝的套件會受到 TuxCare CENTOS-STREAM8：CLSA-2026：1777614769 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 (CVE-2021-47101)

  - 已解決 Linux 核心中的下列弱點：NFSD: Protect against send buffer overflow in NFSv2 READ Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case. (CVE-2022-50410)

  - 已解決 Linux 核心中的下列弱點：scsi: libsas: Fix use-after-free bug in smp_execute_task_sg() When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to delete slow_task->timer. However, if the timer handler sas_task_internal_timedout() is running, the del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below:
    (thread 1) | (thread 2) smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ...
    sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the task->slow_task is deallocated. (CVE-2022-50422)

  - 已解決 Linux 核心中的下列弱點：VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF The call to get_user_pages_fast() in vmci_host_setup_notify() can return NULL context->notify_page causing a GPF. To avoid GPF check if context->notify_page == NULL and return error if so. general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x0005088000000300-0x0005088000000307] CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0 Call Trace:
    <TASK> vmci_host_unlocked_ioctl+0x362/0x1f40 __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2023-53259)

  - 已解決 Linux 核心中的下列弱點：Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data. (CVE-2024-35965)

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

遠端 Debian 11 主機已安裝受到多個弱點影響的套件如 dla-4327 公告中所提及。

    -------------------------------------------------- ----------------------- Debian LTS 公告 DLA-4327-1 debian-lts@lists.debian.org https://www.debian.org/lts/security/Ben Hutchings 2025 年 10 月 13 日 https://wiki.debian.org/LTS-------------------------------------------------------------------------

    套件：linux 版本：5.10.244-1 CVE ID：CVE-2021-46987 CVE-2021-47037 CVE-2021-47070 CVE-2021-47076 CVE-2021-47183 CVE-2021-47193 CVE-2021-47412 CVE-2021-47421 CVE-2021-47455 CVE-2021-47498 CVE-2022-21546 CVE-2022-49063 CVE-2022-50327 CVE-2023-52935 CVE-2023-53259 CVE-2024-26739 CVE-2024-28956 CVE-2024-35790 CVE-2024-36350 CVE-2024-36357 CVE-2024-38541 CVE-2024-43863 CVE-2024-46751 CVE-2024-46855 CVE-2024-49935 CVE-2024-53203 CVE-2024-57883 CVE-2024-57996 CVE-2025-21912 CVE-2025-37798 CVE-2025-37819 CVE-2025-37890 CVE-2025-37909 CVE-2025-37913 CVE-2025-37914 CVE-2025-37915 CVE-2025-37923 CVE-2025-37927 CVE-2025-37930 CVE-2025-37932 CVE-2025-37948 CVE-2025-37949 CVE-2025-37958 CVE-2025-37963 CVE-2025-37968 CVE-2025-37969 CVE-2025-37970 CVE-2025-37990 CVE-2025-37992 CVE-2025-37994 CVE-2025-37995 CVE-2025-37997 CVE-2025-37998 CVE-2025-38000 CVE-2025-38001 CVE-2025-38003 CVE-2025-38004 CVE-2025-38005 CVE-2025-38009 CVE-2025-38023 CVE-2025-38024 CVE-2025-38031 CVE-2025-38034 CVE-2025-38035 CVE-2025-38037 CVE-2025-38044 CVE-2025-38051 CVE-2025-38052 CVE-2025-38058 CVE-2025-38061 CVE-2025-38065 CVE-2025-38066 CVE-2025-38067 CVE-2025-38072 CVE-2025-38074 CVE-2025-38075 CVE-2025-38078 CVE-2025-38079 CVE-2025-38083 CVE-2025-38084 CVE-2025-38085 CVE-2025-38086 CVE-2025-38090 CVE-2025-38094 CVE-2025-38095 CVE-2025-38100 CVE-2025-38102 CVE-2025-38103 CVE-2025-38107 CVE-2025-38108 CVE-2025-38111 CVE-2025-38112 CVE-2025-38115 CVE-2025-38135 CVE-2025-38136 CVE-2025-38138 CVE-2025-38143 CVE-2025-38145 CVE-2025-38146 CVE-2025-38147 CVE-2025-38153 CVE-2025-38157 CVE-2025-38160 CVE-2025-38161 CVE-2025-38163 CVE-2025-38173 CVE-2025-38174 CVE-2025-38177 CVE-2025-38180 CVE-2025-38181 CVE-2025-38184 CVE-2025-38185 CVE-2025-38190 CVE-2025-38193 CVE-2025-38194 CVE-2025-38197 CVE-2025-38200 CVE-2025-38203 CVE-2025-38204 CVE-2025-38206 CVE-2025-38211 CVE-2025-38212 CVE-2025-38214 CVE-2025-38218 CVE-2025-38219 CVE-2025-38222 CVE-2025-38226 CVE-2025-38227 CVE-2025-38229 CVE-2025-38230 CVE-2025-38231 CVE-2025-38237 CVE-2025-38245 CVE-2025-38249 CVE-2025-38251 CVE-2025-38263 CVE-2025-38273 CVE-2025-38285 CVE-2025-38286 CVE-2025-38293 CVE-2025-38298 CVE-2025-38312 CVE-2025-38313 CVE-2025-38320 CVE-2025-38323 CVE-2025-38324 CVE-2025-38326 CVE-2025-38328 CVE-2025-38332 CVE-2025-38336 CVE-2025-38337 CVE-2025-38342 CVE-2025-38344 CVE-2025-38345 CVE-2025-38346 CVE-2025-38347 CVE-2025-38348 CVE-2025-38350 CVE-2025-38352 CVE-2025-38363 CVE-2025-38371 CVE-2025-38375 CVE-2025-38377 CVE-2025-38386 CVE-2025-38387 CVE-2025-38389 CVE-2025-38391 CVE-2025-38393 CVE-2025-38395 CVE-2025-38399 CVE-2025-38400 CVE-2025-38401 CVE-2025-38403 CVE-2025-38404 CVE-2025-38406 CVE-2025-38415 CVE-2025-38416 CVE-2025-38420 CVE-2025-38424 CVE-2025-38428 CVE-2025-38430 CVE-2025-38439 CVE-2025-38445 CVE-2025-38448 CVE-2025-38457 CVE-2025-38458 CVE-2025-38459 CVE-2025-38460 CVE-2025-38461 CVE-2025-38462 CVE-2025-38464 CVE-2025-38465 CVE-2025-38466 CVE-2025-38467 CVE-2025-38468 CVE-2025-38470 CVE-2025-38473 CVE-2025-38474 CVE-2025-38476 CVE-2025-38477 CVE-2025-38478 CVE-2025-38480 CVE-2025-38481 CVE-2025-38482 CVE-2025-38483 CVE-2025-38487 CVE-2025-38488 CVE-2025-38494 CVE-2025-38495 CVE-2025-38497 CVE-2025-38498 CVE-2025-38513 CVE-2025-38514 CVE-2025-38515 CVE-2025-38516 CVE-2025-38529 CVE-2025-38530 CVE-2025-38535 CVE-2025-38538 CVE-2025-38539 CVE-2025-38540 CVE-2025-38542 CVE-2025-38546 CVE-2025-38548 CVE-2025-38553 CVE-2025-38555 CVE-2025-38563 CVE-2025-38565 CVE-2025-38569 CVE-2025-38572 CVE-2025-38574 CVE-2025-38577 CVE-2025-38578 CVE-2025-38581 CVE-2025-38601 CVE-2025-38602 CVE-2025-38604 CVE-2025-38608 CVE-2025-38612 CVE-2025-38617 CVE-2025-38618 CVE-2025-38622 CVE-2025-38635 CVE-2025-38639 CVE-2025-38650 CVE-2025-38652 CVE-2025-38663 CVE-2025-38664 CVE-2025-38666 CVE-2025-38668 CVE-2025-38671 CVE-2025-38676 CVE-2025-38677 CVE-2025-38680 CVE-2025-38681 CVE-2025-38683 CVE-2025-38684 CVE-2025-38687 CVE-2025-38691 CVE-2025-38693 CVE-2025-38694 CVE-2025-38695 CVE-2025-38697 CVE-2025-38698 CVE-2025-38699 CVE-2025-38700 CVE-2025-38701 CVE-2025-38706 CVE-2025-38708 CVE-2025-38712 CVE-2025-38713 CVE-2025-38714 CVE-2025-38715 CVE-2025-38718 CVE-2025-38721 CVE-2025-38724 CVE-2025-38727 CVE-2025-38729 CVE-2025-38732 CVE-2025-39676 CVE-2025-39681 CVE-2025-39683 CVE-2025-39687 CVE-2025-39689 CVE-2025-39691 CVE-2025-39697 CVE-2025-39703 CVE-2025-39709 CVE-2025-39710 CVE-2025-39713 CVE-2025-39714 CVE-2025-39724 CVE-2025-39730 CVE-2025-39736 CVE-2025-39737 CVE-2025-39742 CVE-2025-39743 CVE-2025-39749 CVE-2025-39752 CVE-2025-39756 CVE-2025-39757 CVE-2025-39760 CVE-2025-39766 CVE-2025-39782 CVE-2025-39783 CVE-2025-39787 CVE-2025-39788 CVE-2025-39794 CVE-2025-39795 CVE-2025-39798 CVE-2025-39808 CVE-2025-39812 CVE-2025-39813 CVE-2025-39817 CVE-2025-39823 CVE-2025-39824 CVE-2025-39828 CVE-2025-39835 CVE-2025-39839 CVE-2025-39841 CVE-2025-39846 CVE-2025-39847 CVE-2025-39848 CVE-2025-39853 CVE-2025-39860 CVE-2025-39864 CVE-2025-39865 CVE-2025-39891 CVE-2025-39898 CVE-2025-39902 CVE-2025-39920 CVE-2025-40300 Debian 錯誤：1040901 1109891

    在 Linux 核心中發現數個弱點，這些弱點可能會導致特權提升、拒絕服務或資訊洩漏。

    針對 Debian 11 Bullseye，已在 5.10.244-1 版本中修正這些問題。從此版本開始arm64 也提供 hyperv-daemons 套件且所有架構上的模組皆以暫時金鑰簽署。此版本還包含來自穩定更新的許多錯誤修正 5.10.238-5.10.244。

    建議您升級 linux 套件。

    如需有關 linux 安全性狀態的詳細資訊，請參閱其安全追蹤頁面：
    https://security-tracker.debian.org/tracker/linux

    有關 Debian LTS 安全公告、如何將這些更新套用至您的系統以及常見問題的詳細資訊，請參閱：https://wiki.debian.org/LTSAttachment:signature.ascDescription: PGP signature

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

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

CentOS Linux 8.5 主機安裝的套件會受到 TuxCare CENTOS8.5：CLSA-2026：1771077729 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已解決 Linux 核心中的下列弱點：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已解決 Linux 核心中的下列弱點：be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.
    Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once. (CVE-2022-49581)

  - 已解決 Linux 核心中的下列弱點：dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled). (CVE-2022-49674)

  - 已解決 Linux 核心中的下列弱點：tracing: Fix wild-memory-access in register_synth_event() In register_synth_event(), if set_synth_event_print_fmt() failed, then both trace_remove_event_call() and unregister_trace_event() will be called, which means the trace_event_call will call __unregister_trace_event() twice. As the result, the second unregister will causes the wild-memory-access. register_synth_event set_synth_event_print_fmt failed trace_remove_event_call event_remove if call->event.funcs then __unregister_trace_event (first call) unregister_trace_event
    __unregister_trace_event (second call) Fix the bug by avoiding to call the second
    __unregister_trace_event() by checking if the first one is called. general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] CPU: 0 PID: 3807 Comm: modprobe Not tainted 6.1.0-rc1-00186-g76f33a7eedb4 #299 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_trace_event+0x6e/0x280 Code:
    00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b RSP:
    0018:ffff88810413f370 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 RBP: dead000000000100 R08:
    0000000000000000 R09: fffffbfff0913481 R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>
    __create_synth_event+0x1e37/0x1eb0 create_or_delete_synth_event+0x110/0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-49799)

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

CentOS Linux 7 主機安裝的套件會受到 TuxCare CENTOS7：CLSA-2026：1773056241 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF The call to get_user_pages_fast() in vmci_host_setup_notify() can return NULL context->notify_page causing a GPF. To avoid GPF check if context->notify_page == NULL and return error if so. general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x0005088000000300-0x0005088000000307] CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0 Call Trace:
    <TASK> vmci_host_unlocked_ioctl+0x362/0x1f40 __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2023-53259)

  - 已解決 Linux 核心中的下列弱點：Bluetooth: fix use-after-free in device_for_each_child() Syzbot has reported the following KASAN splat: BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0 Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980 CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x100/0x190 ? device_for_each_child+0x18f/0x1a0 print_report+0x13a/0x4cb ?
    __virt_addr_valid+0x5e/0x590 ? __phys_addr+0xc6/0x150 ? device_for_each_child+0x18f/0x1a0 kasan_report+0xda/0x110 ? device_for_each_child+0x18f/0x1a0 ? __pfx_dev_memalloc_noio+0x10/0x10 device_for_each_child+0x18f/0x1a0 ? __pfx_device_for_each_child+0x10/0x10 pm_runtime_set_memalloc_noio+0xf2/0x180 netdev_unregister_kobject+0x1ed/0x270 unregister_netdevice_many_notify+0x123c/0x1d80 ? __mutex_trylock_common+0xde/0x250 ?
    __pfx_unregister_netdevice_many_notify+0x10/0x10 ? trace_contention_end+0xe6/0x140 ?
    __mutex_lock+0x4e7/0x8f0 ? __pfx_lock_acquire.part.0+0x10/0x10 ? rcu_is_watching+0x12/0xc0 ? unregister_netdev+0x12/0x30 unregister_netdevice_queue+0x30d/0x3f0 ?
    __pfx_unregister_netdevice_queue+0x10/0x10 ? __pfx_down_write+0x10/0x10 unregister_netdev+0x1c/0x30 bnep_session+0x1fb3/0x2ab0 ? __pfx_bnep_session+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ?
    __pfx_woken_wake_function+0x10/0x10 ? __kthread_parkme+0x132/0x200 ? __pfx_bnep_session+0x10/0x10 ? kthread+0x13a/0x370 ? __pfx_bnep_session+0x10/0x10 kthread+0x2b7/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x48/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 4974: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0
    __kmalloc_noprof+0x1d1/0x440 hci_alloc_dev_priv+0x1d/0x2820 __vhci_create_device+0xef/0x7d0 vhci_write+0x2c7/0x480 vfs_write+0x6a0/0xfc0 ksys_write+0x12f/0x260 do_syscall_64+0xc7/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 4979: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x4f/0x70 kfree+0x141/0x490 hci_release_dev+0x4d9/0x600 bt_host_release+0x6a/0xb0 device_release+0xa4/0x240 kobject_put+0x1ec/0x5a0 put_device+0x1f/0x30 vhci_release+0x81/0xf0 __fput+0x3f6/0xb30 task_work_run+0x151/0x250 do_exit+0xa79/0x2c30 do_group_exit+0xd5/0x2a0 get_signal+0x1fcd/0x2210 arch_do_signal_or_restart+0x93/0x780 syscall_exit_to_user_mode+0x140/0x290 do_syscall_64+0xd4/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f In 'hci_conn_del_sysfs()', 'device_unregister()' may be called when an underlying (kobject) reference counter is greater than 1. This means that reparenting (happened when the device is actually freed) is delayed and, during that delay, parent controller device (hciX) may be deleted. Since the latter may create a dangling pointer to freed parent, avoid that scenario by reparenting to NULL explicitly. (CVE-2024-53237)

  - 已解決 Linux 核心中的下列弱點：wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2024-58014)

  - 已解決 Linux 核心中的下列弱點：partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().
    (CVE-2025-21772)

  - 已解決 Linux 核心中的下列弱點：net: ppp: Add bound checking for skb data on ppp_sync_txmung Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets. When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 } from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4, data = 0xffff88803346f416 :\377, truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0, it is not safe to access data[2]. [pabeni@redhat.com: fixed subj typo] (CVE-2025-37749)

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

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

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

    drm修正因 drmm_mode_config_init() 引起的潛在 null-ptr-deref (CVE-2022-50556)

    在 Linux 核心以 io_uring 處理 IORING_OP_SOCKET 作業的過程中發現一個雙重釋放弱點。 (CVE-2023-1032)

    由於初始化期間的類型混淆問題，Linux 核心中的 tun 和 tap 通訊端將其通訊端 UID 硬式編碼為 0 (即 root)。雖然這通常是正確的，因為 TUN/TAP 裝置需要 CAP_NET_ADMIN，但也存在例外情況。通訊端 UID 可用於網路篩选和路由，因此可能導致 TUN/TAP 通訊端管理方式錯誤，進而可能繞過以 UID 為基礎的網路篩選器。(CVE-2023-1076)

    核心：pick_next_rt_entity() 中存在類型混淆弱點，此弱點可導致記憶體損毀。(CVE-2023-1077)

    在使用者卸離 rc 裝置的方式中在 Linux 核心整合式紅外線接收器/收發器驅動程式中發現一個瑕疵。本機使用者可利用此缺陷使系統當機，或可能提升其在系統中的權限。(CVE-2023-1118)

    Linux 核心流量控制索引篩選器 (tcindex) 中的釋放後使用弱點可被利用來提升本機權限。tcindex_delete 函式在刪除基礎結構時未正確停用篩選器，從而會在稍後導致重複釋放該結構。本機攻擊者可利用此弱點來將特權提升為根權限。我們建議使用者升級過去的認可 8c710f75256bb3cf05ac7b1672c82b92c43f3d28。(CVE-2023-1829)

    啟用純文字 IBRS (非增強型 IBRS) 時，spectre_v2_user_select_mitigation() 中的邏輯會判定不需要 STIBP。IBRS 位元可暗中防止跨執行緒分支目標插入。但是，使用舊版 IBRS 時，由於效能原因，IBRS 位元會在傳回至使用者空間時遭到清除，這會使使用者空間執行緒容易受到 STIBP 防範的跨執行緒分支目標插入攻擊。(CVE-2023-1998)

    在 Linux 核心中 fs/hfsplus/super.c 的 hfsplus_put_super 中發現釋放後使用缺陷。本機使用者可利用此缺陷造成拒絕服務。(CVE-2023-2985)

    在 6.2.3 版之前的 Linux 核心中，發現 lib/kobject.c 存在問題。攻擊者可藉由 root 存取權觸發爭用情形，進而導致 fill_kobj_path 超出邊界寫入。(CVE-2023-45863)

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

    vfio/type1防止透過 exec() 發生 locked_vm 的反向溢位 (CVE-2023-53171)

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

    USBuhci透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53197)

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

    netfilterx_tables修正建立新 netns 時錯誤路徑上的 percpu 計數器區塊洩漏 (CVE-2023-53200)

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

    PMdomains使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53202)

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

    驅動程式核心位置在傳回 false 之前釋放結構 acpi_pld_info *pld (CVE-2023-53211)

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

    arm64efi使 efi_rt_lock 成為 raw_spinlock (CVE-2023-53216)

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

    watchdog修正 watchdog_cdev_register 中的 kmemleak (CVE-2023-53234)

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

    xsk在 Tx 路徑中更早檢查 IFF_UP (CVE-2023-53240)

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

    firmwaredmi-sysfs修正 dmi_sysfs_register_handle 中的 null-ptr-deref (CVE-2023-53250)

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

    cacheinfo修正 shared_cpu_map 以處理不同層級的共用快取 (CVE-2023-53254)

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

    VMCI在呼叫 get_user_pages_fast() 之後檢查 context->notify_page 以避免 GPF (CVE-2023-53259)

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

    miscvmw_balloon透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53279)

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

    udf不針對內嵌檔案寫入失敗更新檔案長度 (CVE-2023-53295)

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

    rbd避免當 rbd_dev_create() 失敗時在 do_rbd_add() 中發生釋放後使用 (CVE-2023-53307)

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

    genirq/ipi修正 irq_data_get_affinity_mask() 中的 NULL 指標解除參照 (CVE-2023-53332)

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

    USB修正因使用 debugfs_lookup() 而發生的記憶體洩漏 (CVE-2023-53359)

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

    block輪詢時仔細檢查 NULL bdev (CVE-2023-53366)

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

    cryptoseqiv - 正確處理 EBUSY (CVE-2023-53373)

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

    NFSD修正 nfsd4_ssc_umount_item 的洩漏參照計數 (CVE-2023-53381)

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

    driversbasedd使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53390)

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

    trace/blktrace透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53408)

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

    drivers基礎元件修正因使用 debugfs_lookup() 發生的記憶體洩漏問題 (CVE-2023-53409)

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

    PMEM修正使用 debugfs_lookup() 時發生的記憶體洩漏問題 (CVE-2023-53411)

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

    objtool修正 create_static_call_sections() 中的記憶體洩漏 (CVE-2023-53423)

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

    cifs修正損毀 MR 清單時的警告和 UAF (CVE-2023-53427)

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

    ipv6在 nexthop 計算中新增所有同級的 lwtunnel 封裝大小 (CVE-2023-53477)

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

    iommu修正 iommu_group_alloc() 中的錯誤回溯 (CVE-2023-53482)

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

    cryptoxts - 正確處理 EBUSY (CVE-2023-53494)

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

    udf請勿合併非常長的範圍 (CVE-2023-53506)

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

    io_uring修正 fs 不支援 nowait 緩衝讀取時發生的 fget 洩漏 (CVE-2023-53511)

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

    sctp在 sctp_stream_priorities 中新增 refcnt 以避免巢狀迴圈 (CVE-2023-53590)

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

    驅動程式核心修正 device_add() 中的資源洩漏 (CVE-2023-53594)

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

    nfsd清理 COPY 程式碼路徑中的潛在 nfsd_file refcount 洩漏 (CVE-2023-53606)

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

    irqchip修正 platform_irqchip_probe 中的 refcount 洩漏 (CVE-2023-53610)

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

    nvme-tcp錯誤復原期間不存取已釋放的通訊端 (CVE-2023-53643)

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

    srcu如果使用 SRCU_SIZE_SMALL則將工作委派給開機 cpu (CVE-2023-53671)

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

    drm/i915修正系統在 fbdev 未初始化的情況下暫停 (CVE-2023-53678)

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

    udf偵測連結至目錄階層的系統 inode (CVE-2023-53695)

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

    ring-buffer處理 rb_move_tail 和 rb_check_pages 之間的爭用 (CVE-2023-53709)

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

    KVMVMX修正因未初始化 current_vmcs 而造成的當機 (CVE-2023-53756)

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

    dm 快取釋放 btracker_destroy 中背景追踪器的佇列工作 (CVE-2023-53765)

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

    blk-iocost修正 calc_lcoefs() 中的除以 0 錯誤 (CVE-2023-53783)

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

    iommu/amd改善頁面錯誤錯誤報告 (CVE-2023-53789)

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

    bpf將已配置物件從 bpf 記憶體配置器的平台歸零 (CVE-2023-53790)

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

    PCI修正放置具有 .end = 零的有效 root 匯流排資源 (CVE-2023-53814)

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

    迴圈指派前的 loop_set_status_from_info() 檢查 (CVE-2023-53820)

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

    usbearlyxhci-dbc修正潛在的越界記憶體存取 (CVE-2023-53840)

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

    KVM如果 coalesced MMIO 取消註冊失敗則破壞目標裝置 (CVE-2023-54024)

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

    cryptoesiv - 正確處理 EBUSY (CVE-2023-54046)

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

    iommu/amd為 ivrs_acpihid 命令行參數新增長度限制 (CVE-2023-54057)

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

    blk-cgroup在完成 pd_free_fn() 之後放置父項 refcount (CVE-2023-54107)

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

    ledsled-core修正 of_led_get() 中的 refcount 洩漏 (CVE-2023-54190)

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

    tty修正 tty_driver_lookup_tty() 中的越界存取 (CVE-2023-54198)

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

    netfilterebtables修正表格 blob 釋放後使用 (CVE-2023-54243)

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

    cifsMR 配置失敗時修正遺失的破壞 smbd 連線 (CVE-2023-54260)

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

    ext4拒絕在卸載時建立 ea 區塊 (CVE-2023-54305)

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

    nettls避免在 tx_lock 上懸置工作 (CVE-2023-54306)

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

    dm flakey不損毀零頁面 (CVE-2023-54317)

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

    驅動程式核心修正 device_add() 中潛在的 null-ptr-deref (CVE-2023-54321)

    核心：ctnetlink_create_conntrack() 中的參照計數洩漏問題 (CVE-2023-7192)

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

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

遠端主機上安裝的核心版本早於 5.10.240-238.959。因此，會受到 ALAS2KERNEL-5.10-2025-101 公告中所提及的多個弱點影響。

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

    net：tap：skb->dev 為 null 時，dev_parse_header_protocol 中發生 NULL 指標解除參照 (CVE-2022-50073)

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

    KVM: x86/mmu: 在 NPT 中將 NX 當作有效的 SPTE 位元處理 (CVE-2022-50224)

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

    VMCI在呼叫 get_user_pages_fast() 後檢查 context->notify_page 以避免 GPF (CVE-2023-53259)

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

    ACPI：PAD：修正 exit_round_robin() 中發生損毀的問題 (CVE-2024-49935)

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

    codel：在 before qdisc_tree_reduce_backlog() 之前移除 sch->q.qlen 檢查 (CVE-2025-37798)

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

    sch_htb：使 htb_qlen_notify() 具有冪等性 (CVE-2025-37932)

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

    serial：mctrl_gpio：將 disable_ms 分割為 sync 和 no_sync API (CVE-2025-38040)

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

    virtio：中斷並重設 device_shutdown() 上的 virtio 裝置 (CVE-2025-38064)

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

    rseq: 修復註冊時 rseq_cs 非零導致的分割錯誤 (CVE-2025-38067)

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

    VMCI修正 vmci_host_setup_notify 和 vmci_ctx_unset_notify 之間的爭用 (CVE-2025-38102)

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

    sch_hfsc使 hfsc_qlen_notify() 等冪 (CVE-2025-38177)

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

    net_sched：sch_sfq：拒絕無效的干擾期間 (CVE-2025-38193)

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

    RDMA/iwcm修正 cm_id 解構後工作物件的釋放後使用 (CVE-2025-38211)

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

    bcache修正 cache_set_flush() 中的 NULL 指標 (CVE-2025-38263)

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

    net/sched子類別變空時一律傳送通知 (CVE-2025-38350)

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

    ACPICA如果缺少引數則拒絕評估方法 (CVE-2025-38386)

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

    RDMA/mlx5在 xa_insert 之前初始化 obj_event->obj_sub_list (CVE-2025-38387)

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

    drm/i915/gt修正因 VMA 配置錯誤而保留的時間軸 (CVE-2025-38389)

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

    NFSv4/pNFS修正 NFS_LAYOUT_DRAIN 上的喚醒爭用 (CVE-2025-38393)

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

    scsi目標修正 core_scsi3_decode_spec_i_port() 中的 NULL 指標解除參照 (CVE-2025-38399)

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

    nfsnfs_fs_proc_net_init() 失敗時清理 /proc/net/rpc/nfs。 (CVE-2025-38400)

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

    mtk-sd防止 DMA 對應失敗所造成的記憶體損毀 (CVE-2025-38401)

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

    vsock/vmci初始化 vmci 傳輸封包時將其正確清除 (CVE-2025-38403)

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

    bnxt_en為 XDP_REDIRECT 正確設定 DMA 取消對應 len (CVE-2025-38439)

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

    md/raid1修正 raid1_reshape 中傳回後的堆疊記憶體使用 (CVE-2025-38445)

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

    net/sched如果父類別不存在則中止 __tc_modify_qdisc (CVE-2025-38457)

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

    vsock修正 transport_* TOCTOU (CVE-2025-38461)

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

    vsock修正 transport_{g2h,h2g} TOCTOU (CVE-2025-38462)

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

    tipc修正 tipc_conn_close() 中的釋放後使用。 (CVE-2025-38464)

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

    netlink修正 sk->sk_rmem_alloc 的循環。 (CVE-2025-38465)

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

    perf還原為要求 CAP_SYS_ADMIN 進行 uprobes (CVE-2025-38466)

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

    rxrpc修正因 prealloc backlog 結構不存在所導致的 oops (CVE-2025-38514)

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

    pinctrlqcommsm將特定針腳標記為對中斷無效 (CVE-2025-38516)

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

    HIDquirk新增適用於 2 部 Chicony Electronics HP 5MP 相機的 quirk (CVE-2025-38540)

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

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

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

  - 已解決 Linux 核心中的下列弱點：block, bfq: fix uaf for bfqq in bfq_exit_icq_bfqq Commit 64dc8c732f5c (block, bfq: fix possible uaf for 'bfqq->bic') will access 'bic->bfqq' in bic_set_bfqq(), however, bfq_exit_icq_bfqq() can free bfqq first, and then call bic_set_bfqq(), which will cause uaf. Fix the problem by moving bfq_exit_bfqq() behind bic_set_bfqq().
    (CVE-2022-50329)

  - 已解決 Linux 核心中的下列弱點：block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10:
    ================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace:
    bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0
    __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0
    __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90
    __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d (bfq: Split shared queues on move between cgroups) changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | | | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic. (CVE-2022-50488)

  - 已解決 Linux 核心中的下列弱點：wifi: ath10k: Delay the unmapping of the buffer On WCN3990, we are seeing a rare scenario where copy engine hardware is sending a copy complete interrupt to the host driver while still processing the buffer that the driver has sent, this is leading into an SMMU fault triggering kernel panic. This is happening on copy engine channel 3 (CE3) where the driver normally enqueues WMI commands to the firmware. Upon receiving a copy complete interrupt, host driver will immediately unmap and frees the buffer presuming that hardware has processed the buffer. In the issue case, upon receiving copy complete interrupt, host driver will unmap and free the buffer but since hardware is still accessing the buffer (which in this case got unmapped in parallel), SMMU hardware will trigger an SMMU fault resulting in a kernel panic. In order to avoid this, as a work around, add a delay before unmapping the copy engine source DMA buffer. This is conditionally done for WCN3990 and only for the CE3 channel where issue is seen. Below is the crash signature: wifi smmu error: kernel: [10.120965] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fdfd8ac0, fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandled context fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003, cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal error received: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091: cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149 remoteproc remoteproc0: crash detected in 4080000.remoteproc: type fatal error <3> remoteproc remoteproc0: handling crash #1 in 4080000.remoteproc pc :
    __arm_lpae_unmap+0x500/0x514 lr : __arm_lpae_unmap+0x4bc/0x514 sp : ffffffc011ffb530 x29: ffffffc011ffb590 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000004 x25: 0000000000000003 x24:
    ffffffc011ffb890 x23: ffffffa762ef9be0 x22: ffffffa77244ef00 x21: 0000000000000009 x20: 00000007fff7c000 x19: 0000000000000003 x18: 0000000000000000 x17: 0000000000000004 x16: ffffffd7a357d9f0 x15:
    0000000000000000 x14: 00fd5d4fa7ffffff x13: 000000000000000e x12: 0000000000000000 x11: 00000000ffffffff x10: 00000000fffffe00 x9 : 000000000000017c x8 : 000000000000000c x7 : 0000000000000000 x6 :
    ffffffa762ef9000 x5 : 0000000000000003 x4 : 0000000000000004 x3 : 0000000000001000 x2 : 00000007fff7c000 x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace: __arm_lpae_unmap+0x500/0x514
    __arm_lpae_unmap+0x4bc/0x514 __arm_lpae_unmap+0x4bc/0x514 arm_lpae_unmap_pages+0x78/0xa4 arm_smmu_unmap_pages+0x78/0x104 __iommu_unmap+0xc8/0x1e4 iommu_unmap_fast+0x38/0x48
    __iommu_dma_unmap+0x84/0x104 iommu_dma_free+0x34/0x50 dma_free_attrs+0xa4/0xd0 ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c [ath10k_core] ath10k_halt+0x11c/0x180 [ath10k_core] ath10k_stop+0x54/0x94 [ath10k_core] drv_stop+0x48/0x1c8 [mac80211] ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c [mac80211] __dev_open+0xb4/0x174
    __dev_change_flags+0xc4/0x1dc dev_change_flags+0x3c/0x7c devinet_ioctl+0x2b4/0x580 inet_ioctl+0xb0/0x1b4 sock_do_ioctl+0x4c/0x16c compat_ifreq_ioctl+0x1cc/0x35c compat_sock_ioctl+0x110/0x2ac
    __arm64_compat_sys_ioctl+0xf4/0x3e0 el0_svc_common+0xb4/0x17c el0_svc_compat_handler+0x2c/0x58 el0_svc_compat+0x8/0x2c Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 (CVE-2022-50700)

  - 已解決 Linux 核心中的下列弱點：tcp: fix a signed-integer-overflow bug in tcp_add_backlog() The type of sk_rcvbuf and sk_sndbuf in struct sock is int, and in tcp_add_backlog(), the variable limit is caculated by adding sk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max value of int and overflow. This patch reduces the limit budget by halving the sndbuf to solve this issue since ACK packets are much smaller than the payload. (CVE-2022-50865)

  - 已解決 Linux 核心中的下列弱點：block, bfq: fix uaf for bfqq in bic_set_bfqq() After commit 64dc8c732f5c (block, bfq: fix possible uaf for 'bfqq->bic'), bic->bfqq will be accessed in bic_set_bfqq(), however, in some context bic->bfqq will be freed, and bic_set_bfqq() is called with the freed bic->bfqq. Fix the problem by always freeing bfqq after bic_set_bfqq().
    (CVE-2023-52983)

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

CentOS Linux 8.4 主機已安裝的套件會受到 TuxCare CENTOS8.4：CLSA-2026：1771078945 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已解決 Linux 核心中的下列弱點：i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - 已解決 Linux 核心中的下列弱點：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已解決 Linux 核心中的下列弱點：net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. (CVE-2022-48883)

  - 已解決 Linux 核心中的下列弱點：ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The rxstatus->rs_keyix eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' (CVE-2022-49503)

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

遠端主機上安裝的核心版本早於 5.4.296-217.427。因此，會受到 ALAS2KERNEL-5.4-2025-106 公告中所提及的多個弱點影響。

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

    net：tap：skb->dev 為 null 時，dev_parse_header_protocol 中發生 NULL 指標解除參照 (CVE-2022-50073)

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

    VMCI在呼叫 get_user_pages_fast() 後檢查 context->notify_page 以避免 GPF (CVE-2023-53259)

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

    RDMA/mlx5在損毀 QP/RQ 時傳回韌體結果 (CVE-2023-53286)

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

    btrfs：嘗試拍攝已刪除子磁碟區的快照時，不會中止檔案系統 (CVE-2024-26644)

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

    ACPI：PAD：修正 exit_round_robin() 中發生損毀的問題 (CVE-2024-49935)

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

    serial：mctrl_gpio：將 disable_ms 分割為 sync 和 no_sync API (CVE-2025-38040)

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

    virtio：中斷並重設 device_shutdown() 上的 virtio 裝置 (CVE-2025-38064)

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

    VMCI修正 vmci_host_setup_notify 和 vmci_ctx_unset_notify 之間的爭用 (CVE-2025-38102)

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

    RDMA/mlx5：修正 RQ 解構韌體失敗時的錯誤流程 (CVE-2025-38161)

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

    RDMA/iwcm修正 cm_id 解構後工作物件的釋放後使用 (CVE-2025-38211)

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

    tty序列uartlite在 init 中註冊 uart 驅動程式 (CVE-2025-38262)

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

    net/sched子類別變空時一律傳送通知 (CVE-2025-38350)

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

    ACPICA如果缺少引數則拒絕評估方法 (CVE-2025-38386)

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

    RDMA/mlx5在 xa_insert 之前初始化 obj_event->obj_sub_list (CVE-2025-38387)

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

    nfsnfs_fs_proc_net_init() 失敗時清理 /proc/net/rpc/nfs。 (CVE-2025-38400)

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

    mtk-sd防止 DMA 對應失敗所造成的記憶體損毀 (CVE-2025-38401)

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

    vsock/vmci初始化 vmci 傳輸封包時將其正確清除 (CVE-2025-38403)

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

    bnxt_en為 XDP_REDIRECT 正確設定 DMA 取消對應 len (CVE-2025-38439)

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

    md/raid1修正 raid1_reshape 中傳回後的堆疊記憶體使用 (CVE-2025-38445)

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

    net/sched如果父類別不存在則中止 __tc_modify_qdisc (CVE-2025-38457)

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

    tipc修正 tipc_conn_close() 中的釋放後使用。 (CVE-2025-38464)

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

    netlink修正 sk->sk_rmem_alloc 的循環。 (CVE-2025-38465)

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

    rxrpc修正因 prealloc backlog 結構不存在所導致的 oops (CVE-2025-38514)

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

    pinctrlqcommsm將特定針腳標記為對中斷無效 (CVE-2025-38516)

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

    HIDquirk新增適用於 2 部 Chicony Electronics HP 5MP 相機的 quirk (CVE-2025-38540)

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

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
265033	Linux Distros 未修補的弱點：CVE-2023-53259	Nessus	Misc.	2025/9/16	2026/11/12	high
173235	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。15-2023-015 (ALASKERNEL-5.15-2023-015)	Nessus	Amazon Linux Local Security Checks	2023/3/22	2026/2/9	high
361340	CentOS Linux 8 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc多個漏洞（CENTOS-STREAM8：CLSA-2026：1777614769）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/19	high
270133	Debian dla-4327ata-modules-5.10.0-35-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2025/10/13	2025/10/28	medium
360928	CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc多個弱點（CENTOS8.5：CLSA-2026：1771077729）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/18	high
361774	CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個弱點（CENTOS7：CLSA-2026：1773056241）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
173340	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-138)	Nessus	Amazon Linux Local Security Checks	2023/3/23	2026/2/10	high
246925	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。10-2025-101 (ALASKERNEL-5.10-2025-101)	Nessus	Amazon Linux Local Security Checks	2025/8/9	2026/2/26	high
360081	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1771239384）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
361173	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.4：CLSA-2026：1771078945）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
246921	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。4-2025-106 (ALASKERNEL-5.4-2025-106)	Nessus	Amazon Linux Local Security Checks	2025/8/9	2026/2/26	high

偵測

搜尋 Plugin

high

high

high

medium

high

high

high

high

high

high

high