遠端 Oracle Linux 10 / 9 主機已安裝受到多個弱點影響的套件如 ELSA-2025-20530 公告中所提及。

    - sunrpc將 svc 驗證處理期間視為驗證錯誤的 SVC_GARBAGE處理 (Jeff Layton) [Orabug: 38137447] {CVE-2025-38089}
    - 新增 Zen34 用戶端 (Borislav Petkov (AMD)) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}
    - x86/處理程序將緩衝區清除移至 MONITOR 之前 (Kim Phillips) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}
    - 新增一般計數器 (Borislav Petkov (AMD)) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}
    - KVMSVM將 TSA CPUID 位元公告給客體 (Borislav Petkov (AMD)) [Orabug38172252] {CVE-2024-36350} {CVE-2024-36357}
    - x86/錯誤新增暫時性排程器攻擊緩解 (Borislav Petkov (AMD)) [Orabug38172252] {CVE-2024-36350} {CVE-2024-36357}

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

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

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

  - 已解決 Linux 核心中的下列弱點：firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails. (CVE-2022-50087)

  - 已解決 Linux 核心中的下列弱點：wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit() There is a global-out-of-bounds reported by KASAN: BUG:
    KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ...
    kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae] ...
    </TASK> The root cause of the problem is that the comparison order of prate_section in
    _rtl8812ae_phy_set_txpower_limit() is wrong. The _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two strings from tail to head, which causes the problem. In the
    _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet this requirement by carefully designing the comparison order. For example, pregulation and pbandwidth are compared in order of length from small to large, first is 3 and last is 4. However, the comparison order of prate_section dose not obey such order requirement, therefore when prate_section is HT, when comparing from tail to head, it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As mentioned above, the
    _rtl8812ae_eq_n_byte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing
    _rtl8812ae_eq_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of prate_section, this may cause the value of rate_section to not be from 0 to 5. In addition, commit 21e4b0726dc6 not only moved driver from staging to regular tree, but also added setting txpower limit function during the driver config phase, so the problem was introduced by this commit. (CVE-2022-50279)

  - 已解決 Linux 核心中的下列弱點：wifi: ath11k: fix monitor mode bringup crash When the interface is brought up in monitor mode, it leads to NULL pointer dereference crash. This crash happens when the packet type is extracted for a SKB. This extraction which is present in the received msdu delivery path,is not needed for the monitor ring packets since they are all RAW packets.
    Hence appending the flags with RX_FLAG_ONLY_MONITOR to skip that extraction. Observed calltrace: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000064 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable:
    4k pages, 48-bit VAs, pgdp=0000000048517000 [0000000000000064] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: ath11k_pci ath11k qmi_helpers CPU: 2 PID: 1781 Comm: napi/-271 Not tainted 6.1.0-rc5-wt-ath-656295-gef907406320c-dirty #6 Hardware name:
    Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k] lr :
    ath11k_hw_qcn9074_rx_desc_get_decap_type+0x5c/0x60 [ath11k] sp : ffff80000ef5bb10 x29: ffff80000ef5bb10 x28: 0000000000000000 x27: ffff000007baafa0 x26: ffff000014a91ed0 x25: 0000000000000000 x24:
    0000000000000000 x23: ffff800002b77378 x22: ffff000014a91ec0 x21: ffff000006c8d600 x20: 0000000000000000 x19: ffff800002b77740 x18: 0000000000000006 x17: 736564203634343a x16: 656e694c20657079 x15:
    0000000000000143 x14: 00000000ffffffea x13: ffff80000ef5b8b8 x12: ffff80000ef5b8c8 x11: ffff80000a591d30 x10: ffff80000a579d40 x9 : c0000000ffffefff x8 : 0000000000000003 x7 : 0000000000017fe8 x6 :
    ffff80000a579ce8 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 3a35ec12ed7f8900 x1 : 0000000000000000 x0 : 0000000000000052 Call trace: ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k] ath11k_dp_rx_deliver_msdu.isra.42+0xa4/0x3d0 [ath11k] ath11k_dp_rx_mon_deliver.isra.43+0x2f8/0x458 [ath11k] ath11k_dp_rx_process_mon_rings+0x310/0x4c0 [ath11k] ath11k_dp_service_srng+0x234/0x338 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xb8 [ath11k]
    __napi_poll+0x5c/0x190 napi_threaded_poll+0xf0/0x118 kthread+0xf4/0x110 ret_from_fork+0x10/0x20 Tested-on:
    QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 (CVE-2022-50627)

  - 已解決 Linux 核心中的下列弱點：mm: hugetlb: fix UAF in hugetlb_handle_userfault The vma_lock and hugetlb_fault_mutex are dropped before handling userfault and reacquire them again after handle_userfault(), but reacquire the vma_lock could lead to UAF[1,2] due to the following race, hugetlb_fault hugetlb_no_page /*unlock vma_lock */ hugetlb_handle_userfault handle_userfault /* unlock mm->mmap_lock*/ vm_mmap_pgoff do_mmap mmap_region munmap_vma_range /* clean old vma */ /* lock vma_lock again <--- UAF */ /* unlock vma_lock */ Since the vma_lock will unlock immediately after hugetlb_handle_userfault(), let's drop the unneeded lock and unlock in hugetlb_handle_userfault() to fix the issue. [1] https://lore.kernel.org/linux-mm/000000000000d5e00a05e834962e@google.com/ [2] https://lore.kernel.org/linux-mm/20220921014457.1668-1-liuzixian4@huawei.com/ (CVE-2022-50630)

  - 已解決 Linux 核心中的下列弱點：PCI: Fix pci_device_is_present() for VFs by checking PF pci_device_is_present() previously didn't work for VFs because it reads the Vendor and Device ID, which are 0xffff for VFs, which looks like they aren't present. Check the PF instead. Wei Gong reported that if virtio I/O is in progress when the driver is unbound or 0 is written to /sys/.../sriov_numvfs, the virtio I/O operation hangs, which may result in output like this: task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 Call Trace: schedule+0x4f/0xc0 blk_mq_freeze_queue_wait+0x69/0xa0 blk_mq_freeze_queue+0x1b/0x20 blk_cleanup_queue+0x3d/0xd0 virtblk_remove+0x3c/0xb0 [virtio_blk] virtio_dev_remove+0x4b/0x80 ... device_unregister+0x1b/0x60 unregister_virtio_device+0x18/0x30 virtio_pci_remove+0x41/0x80 pci_device_remove+0x3e/0xb0 This happened because pci_device_is_present(VF) returned false in virtio_pci_remove(), so it called virtio_break_device(). The broken vq meant that vring_interrupt() skipped the vq.callback() that would have completed the virtio I/O operation via virtblk_done(). [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag] (CVE-2022-50636)

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

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

  - Bluetooth： MGMT：修正可能的鎖死 這修正了可能的鎖死，例如由 hci_cmd_sync_dequeue導致 destroy 函式執行而引起的鎖死： INFO：任務 kworker/u19：0：143 被封鎖超過 120 秒。污點：G W O 6.8。0-2024-03-19-intel-next-iLS-24ww14 #1 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 停用此訊息。 task：kworker/u19：0 state：D stack：0 pid：143 tgid：143 ppid：2 flags：0x00004000 工作佇列：hci0 hci_cmd_sync_work [bluetooth] 呼叫追蹤： <TASK>
    __schedule+0x374/0xaf0檔+0x3c/0xf0 schedule_preempt_disabled+0x1c/0x30
    __mutex_lock.constprop.0+0x3ef/0x7a0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3c/0x50 mgmt_set_connectable_complete+0xa4/0x150 [藍牙] ？kfree+0x211/0x2a0 hci_cmd_sync_dequeue+0xae/0x130 [藍牙] ？__pfx_cmd_complete_rsp+0x10/0x10 [藍牙] cmd_complete_rsp+0x26/0x80 [藍牙] mgmt_pending_foreach+0x4d/0x70 [藍牙] __mgmt_power_off+0x8d/0x180 [藍牙] ？
    _raw_spin_unlock_irq+0x23/0x40 hci_dev_close_sync+0x445/0x5b0 [藍牙] hci_set_powered_sync+0x149/0x250 [藍牙] set_powered_sync+0x24/0x60 [藍牙] hci_cmd_sync_work+0x90/0x150 [藍牙] process_one_work+0x13e/0x300 worker_thread+0x2f7/0x420 ？__pfx_worker_thread+0x10/0x10 kthread+0x107/0x140 ？__pfx_kthread+0x10/0x10 ret_from_fork+0x3d/0x60？__pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> （CVE-2024-53207）

請注意，Nessus 依賴供應商報告的套件存在。

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

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

    套件：linux-6.1 版本：6.1.6.1.128-1~deb11u1 CVE ID：CVE-2022-49034 CVE-2023-52916 CVE-2023-52926 CVE-2024-26595 CVE-2024-27407 CVE-2024-35870 CVE-2024-35956 CVE-2024-36476 CVE-2024-36479 CVE-2024-36899 CVE-2024-37021 CVE-2024-39282 CVE-2024-41014 CVE-2024-42252 CVE-2024-42315 CVE-2024-42319 CVE-2024-43098 CVE-2024-44950 CVE-2024-45828 CVE-2024-46809 CVE-2024-46841 CVE-2024-46896 CVE-2024-47143 CVE-2024-47408 CVE-2024-47745 CVE-2024-48881 CVE-2024-49571 CVE-2024-49861 CVE-2024-49891 CVE-2024-49897 CVE-2024-49898 CVE-2024-49899 CVE-2024-49909 CVE-2024-49911 CVE-2024-49915 CVE-2024-49917 CVE-2024-49925 CVE-2024-49929 CVE-2024-49934 CVE-2024-49939 CVE-2024-49951 CVE-2024-49994 CVE-2024-49996 CVE-2024-50014 CVE-2024-50047 CVE-2024-50051 CVE-2024-50055 CVE-2024-50121 CVE-2024-50146 CVE-2024-50164 CVE-2024-50248 CVE-2024-50258 CVE-2024-50275 CVE-2024-50304 CVE-2024-52332 CVE-2024-53099 CVE-2024-53105 CVE-2024-53124 CVE-2024-53125 CVE-2024-53128 CVE-2024-53141 CVE-2024-53142 CVE-2024-53145 CVE-2024-53146 CVE-2024-53148 CVE-2024-53150 CVE-2024-53151 CVE-2024-53154 CVE-2024-53155 CVE-2024-53156 CVE-2024-53157 CVE-2024-53158 CVE-2024-53161 CVE-2024-53164 CVE-2024-53165 CVE-2024-53170 CVE-2024-53171 CVE-2024-53172 CVE-2024-53173 CVE-2024-53174 CVE-2024-53175 CVE-2024-53180 CVE-2024-53181 CVE-2024-53183 CVE-2024-53184 CVE-2024-53190 CVE-2024-53194 CVE-2024-53196 CVE-2024-53197 CVE-2024-53198 CVE-2024-53206 CVE-2024-53207 CVE-2024-53208 CVE-2024-53210 CVE-2024-53213 CVE-2024-53214 CVE-2024-53215 CVE-2024-53217 CVE-2024-53220 CVE-2024-53226 CVE-2024-53227 CVE-2024-53229 CVE-2024-53230 CVE-2024-53231 CVE-2024-53233 CVE-2024-53234 CVE-2024-53237 CVE-2024-53239 CVE-2024-53240 CVE-2024-53241 CVE-2024-53680 CVE-2024-53685 CVE-2024-53690 CVE-2024-54031 CVE-2024-55881 CVE-2024-55916 CVE-2024-56369 CVE-2024-56531 CVE-2024-56532 CVE-2024-56533 CVE-2024-56539 CVE-2024-56546 CVE-2024-56548 CVE-2024-56551 CVE-2024-56557 CVE-2024-56558 CVE-2024-56562 CVE-2024-56567 CVE-2024-56568 CVE-2024-56569 CVE-2024-56570 CVE-2024-56572 CVE-2024-56574 CVE-2024-56575 CVE-2024-56576 CVE-2024-56578 CVE-2024-56579 CVE-2024-56581 CVE-2024-56582 CVE-2024-56584 CVE-2024-56585 CVE-2024-56586 CVE-2024-56587 CVE-2024-56589 CVE-2024-56590 CVE-2024-56593 CVE-2024-56594 CVE-2024-56595 CVE-2024-56596 CVE-2024-56597 CVE-2024-56598 CVE-2024-56599 CVE-2024-56600 CVE-2024-56601 CVE-2024-56602 CVE-2024-56603 CVE-2024-56604 CVE-2024-56605 CVE-2024-56606 CVE-2024-56608 CVE-2024-56610 CVE-2024-56614 CVE-2024-56615 CVE-2024-56616 CVE-2024-56619 CVE-2024-56622 CVE-2024-56623 CVE-2024-56625 CVE-2024-56626 CVE-2024-56627 CVE-2024-56628 CVE-2024-56629 CVE-2024-56630 CVE-2024-56631 CVE-2024-56633 CVE-2024-56634 CVE-2024-56636 CVE-2024-56637 CVE-2024-56640 CVE-2024-56642 CVE-2024-56643 CVE-2024-56644 CVE-2024-56645 CVE-2024-56648 CVE-2024-56650 CVE-2024-56651 CVE-2024-56658 CVE-2024-56659 CVE-2024-56660 CVE-2024-56661 CVE-2024-56662 CVE-2024-56663 CVE-2024-56664 CVE-2024-56665 CVE-2024-56670 CVE-2024-56672 CVE-2024-56675 CVE-2024-56677 CVE-2024-56678 CVE-2024-56679 CVE-2024-56681 CVE-2024-56683 CVE-2024-56687 CVE-2024-56688 CVE-2024-56690 CVE-2024-56691 CVE-2024-56693 CVE-2024-56694 CVE-2024-56698 CVE-2024-56700 CVE-2024-56701 CVE-2024-56703 CVE-2024-56704 CVE-2024-56705 CVE-2024-56707 CVE-2024-56708 CVE-2024-56709 CVE-2024-56715 CVE-2024-56716 CVE-2024-56717 CVE-2024-56718 CVE-2024-56720 CVE-2024-56722 CVE-2024-56723 CVE-2024-56724 CVE-2024-56725 CVE-2024-56726 CVE-2024-56727 CVE-2024-56728 CVE-2024-56739 CVE-2024-56741 CVE-2024-56745 CVE-2024-56746 CVE-2024-56747 CVE-2024-56748 CVE-2024-56751 CVE-2024-56754 CVE-2024-56755 CVE-2024-56756 CVE-2024-56759 CVE-2024-56763 CVE-2024-56765 CVE-2024-56766 CVE-2024-56767 CVE-2024-56769 CVE-2024-56770 CVE-2024-56774 CVE-2024-56776 CVE-2024-56777 CVE-2024-56778 CVE-2024-56779 CVE-2024-56780 CVE-2024-56781 CVE-2024-56783 CVE-2024-56785 CVE-2024-56787 CVE-2024-57791 CVE-2024-57792 CVE-2024-57798 CVE-2024-57802 CVE-2024-57807 CVE-2024-57838 CVE-2024-57841 CVE-2024-57849 CVE-2024-57850 CVE-2024-57874 CVE-2024-57876 CVE-2024-57882 CVE-2024-57884 CVE-2024-57887 CVE-2024-57889 CVE-2024-57890 CVE-2024-57892 CVE-2024-57893 CVE-2024-57894 CVE-2024-57896 CVE-2024-57897 CVE-2024-57900 CVE-2024-57901 CVE-2024-57902 CVE-2024-57903 CVE-2024-57904 CVE-2024-57906 CVE-2024-57907 CVE-2024-57908 CVE-2024-57910 CVE-2024-57911 CVE-2024-57912 CVE-2024-57913 CVE-2024-57916 CVE-2024-57917 CVE-2024-57922 CVE-2024-57925 CVE-2024-57929 CVE-2024-57930 CVE-2024-57931 CVE-2024-57938 CVE-2024-57939 CVE-2024-57940 CVE-2024-57946 CVE-2024-57948 CVE-2024-57949 CVE-2024-57951 CVE-2025-21629 CVE-2025-21631 CVE-2025-21636 CVE-2025-21637 CVE-2025-21638 CVE-2025-21639 CVE-2025-21640 CVE-2025-21646 CVE-2025-21647 CVE-2025-21648 CVE-2025-21653 CVE-2025-21655 CVE-2025-21660 CVE-2025-21662 CVE-2025-21664 CVE-2025-21665 CVE-2025-21666 CVE-2025-21667 CVE-2025-21668 CVE-2025-21669 CVE-2025-21671 CVE-2025-21675 CVE-2025-21678 CVE-2025-21680 CVE-2025-21681 CVE-2025-21683 CVE-2025-21687 CVE-2025-21688 CVE-2025-21689 CVE-2025-21690 CVE-2025-21692 CVE-2025-21694 CVE-2025-21697 CVE-2025-21699

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

    針對 Debian 11 bullseye，這些問題已在 6.1.6.1.128-1~deb11u1 版本中修復。還包含穩定版更新 6.1.120-6.1.128 (含) 中的許多錯誤修正。

    建議您升級 linux-6.1 套件。

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

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

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

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

遠端 Oracle Linux 9 主機中安裝的套件受到 ELSA-2025-20480 公告中提及的多個弱點影響。

    - sunrpc在 svc 驗證處理期間將 SVC_GARBAGE視為驗證錯誤處理 (Jeff Layton) [Orabug: 38178286] {CVE-2025-38089}
    - 新增 Zen34 用戶端 (Borislav Petkov (AMD)) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - x86/處理程序將緩衝區清除移至 MONITOR 之前 (Kim Phillips) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - 新增一般計數器 (Borislav Petkov (AMD)) [Orabug38023239] {CVE-2024-36350} {CVE-2024-36357}
    - KVMSVM將 TSA CPUID 位元公告給客體 (Borislav Petkov (AMD)) [Orabug38023239] {CVE-2024-36350} {CVE-2024-36357}
    - x86/錯誤新增暫時性排程器攻擊緩解 (Borislav Petkov (AMD)) [Orabug38023239] {CVE-2024-36350} {CVE-2024-36357}
    - x86/錯誤將 MDS 機器重新命名為更通用的名稱 (Borislav Petkov (AMD)) [Orabug38023239] {CVE-2024-36350} {CVE-2024-36357}
    - block修正將作品集新增到 bio 的問題 (Ming Lei) [Orabug: 37844657] {CVE-2025-22122}
    - f2fs修正以避免存取未初始化的 curseg (Chao Yu) [Orabug: 37844644] {CVE-2025-22123}
    - gpiovirtuser修正潛在的超出邊界寫入 (Markus Burri) [Orabug: 38095181] {CVE-2025-38082}
    - net_schedhfsc將類別新增至 eltree 的可重入入列解決兩次 (Pedro Tammela) [Orabug:
    38049363] {CVE-2025-38001}
    - smb用戶端修正 cifs_fill_dirent 中的釋放後使用 (Zhaolong Wang) [Orabug: 38094970] {CVE-2025-38051}
    - platform/x86dell-wmi-sysman避免 current_password_store() 中發生緩衝區溢位 (Vladimir Moskovkin) [Orabug: 38095141] {CVE-2025-38077}
    - ALSApcm修正 PCM OSS 層的緩衝區存取爭用 (Takashi Iwai) [Orabug: 38095145] {CVE-2025-38078}
    - canbcm針對 procfs 內容新增缺少的 rcu 讀取保護 (Oliver Hartkopp) [Orabug: 38049369] {CVE-2025-38003}
    - canbcm為 bcm_op 運行時間更新新增鎖定 (Oliver Hartkopp) [Orabug: 38049374] {CVE-2025-38004}
    - padata不洩漏 reorder_work 中的 refcount (Dominik Grzegorzek) [Orabug: 38094842] {CVE-2025-38031}
    - cryptoalgif_hash - 修正 hash_accept 中的重複釋放 (Ivan Pravdin) [Orabug: 38095153] {CVE-2025-38079}
    - net/tipc修正 tipc_aead_encrypt_done 中的 slab-use-after-free 讀取 (Wang Liang) [Orabug: 38094978] {CVE-2025-38052}
    - sch_hfsc修正在 hfsc_enqueue() 中使用 peek 時的 qlen 計量錯誤 (Cong Wang) [Orabug: 38049357] {CVE-2025-38000}
    - idpf修正 idpf_features_check 中的 null-ptr-deref (Pavan Kumar Linga) [Orabug: 38094982] {CVE-2025-38053}
    - ptpocp限制摘要輸出函式中的訊號/頻率計數 (Sagi Maimon) [Orabug: 38094984] {CVE-2025-38054}
    - perf/x86/intel使用 sample_freq 修正 PEBS-via-PT 的 segfault (Adrian Hunter) [Orabug: 38094988] {CVE-2025-38055}
    - ASoCSOFIntelhda重新載入模組時修正 UAF (Tavian Barnes) [Orabug: 38094991] {CVE-2025-38056}
    - espintcp修正 skb 洩漏 (Sabrina Dubroca) [Orabug: 38094993] {CVE-2025-38057}
    - __legitimize_mnt()MNT_SYNC_UMOUNT 的檢查應位於 mount_lock 之下 (Al Viro) [Orabug38095000] {CVE-2025-38058}
    - x86/Kconfig使 CFI_AUTO_DEFAULT 相依於 !RUST 或 Rust >= 1.88 (Pawel Anikiel) [Orabug38094847] {CVE-2025-38033}
    - btrfs如果沒有有效的 csum 樹狀結構避免 NULL 指標解除參照 (Qu Wenruo) [Orabug: 38095010] {CVE-2025-38059}
    - btrfs更正 btrfs__prelim_ref 中 prelim_ref 引數的順序 (Goldwyn Rodrigues) [Orabug:
    38094856] {CVE-2025-38034}
    - nvmet-tcp不還原 null sk_state_change (Alistair Francis) [Orabug: 38094863] {CVE-2025-38035}
    - vxlan註釋 FDB 資料爭用 (Ido Schimmel) [Orabug: 38094879] {CVE-2025-38037}
    - cpufreqamd-pstate移除 set_boost 中不必要的 driver_lock (Dhananjay Ugwekar) [Orabug: 38094888] {CVE-2025-38038}
    - drm/amd/display增加 block_sequence 陣列大小 (Joshua Aberback) [Orabug: 38095164] {CVE-2025-38080}
    - bpfcopy_verifier_state() 應複製 'loop_entry' 欄位 (Eduard Zingerman) [Orabug: 38095018] {CVE-2025-38060}
    - serialmctrl_gpio將 disable_ms 分割為 sync 和 no_sync API (Alexis Lothore) [Orabug: 38094901] {CVE-2025-38040}
    - net: pktgen修正 pktgen_thread_write() 中使用者指定緩衝區之外的存取 (Peter Seiderer) [Orabug:
    38095024] {CVE-2025-38061}
    - genirq/msi將 IOMMU IOVA 直接儲存在 msi_desc 中而非 iommu_cookie 中 (Jason Gunthorpe) [Orabug:
    38095031] {CVE-2025-38062}
    - dm修正由 REQ_PREFLUSH 造成的無條件 IO 節流 (Jinliang Zheng) [Orabug: 38095038] {CVE-2025-38063}
    - firmwarearm_ffa針對 ffa 裝置設定 dma_mask (Viresh Kumar) [Orabug: 38094925] {CVE-2025-38043}
    - mediacx231xx設定 417 的 device_caps (Hans Verkuil) [Orabug: 38094934] {CVE-2025-38044}
    - Orangefs不截斷檔案大小 (Matthew Wilcox) [Orabug: 38095056] {CVE-2025-38065}
    - dm cache透過封鎖失敗的裝置恢復時的重試來防止 BUG_ON (Ming-Hung Tsai) [Orabug
    38095063] {CVE-2025-38066}
    - cryptolzo - 修正壓縮緩衝區滿溢 (Herbert Xu) [Orabug: 38095079] {CVE-2025-38068}
    - PCI: endpoint: pci-epf-test修正導致核心 oops 的重複釋放 (Christian Bruel) [Orabug
    38095087] {CVE-2025-38069}
    - wifiiwlwifi修正除錯動作順序 (Johannes Berg) [Orabug: 38094942] {CVE-2025-38045}
    - x86/mm檢查 memblock_phys_alloc_range() 的傳回值 (Philip Redkin) [Orabug: 38095101] {CVE-2025-38071}
    - libnvdimm/labels修正 nd_label_data_init() 中的除法錯誤 (Robert Richter) [Orabug: 38095109] {CVE-2025-38072}
    - spi-rockchip修正暫存器超出邊界存取 (Luis de Arquer) [Orabug: 38095173] {CVE-2025-38081}
    - x86/fred修正在啟用 FRED 的情況下 S4 恢復期間發生的系統懸置 (Xin Li) [Orabug: 38094951] {CVE-2025-38047}
    - block修正 set_blocksize 和讀取路徑之間的爭用 (Darrick J. Wong) [Orabug: 38095117] {CVE-2025-38073}
    - virtio_ring將 KCSAN 的 event_triggered 標記為 racy進而修正資料爭用 (Zhongqiu Han) [Orabug
    38094958] {CVE-2025-38048}
    - scsi目標iscsi修正刪除的連線逾時 (Dmitry Bogdanov) [Orabug: 38095134] {CVE-2025-38075}
    - usbtypecucsidisplayport修正鎖死 (Andrei Kuzynski) [Orabug: 37977018] {CVE-2025-37967}
    - 藍牙btnxpuart修正 FW 釋放期間的核心錯誤 (Neeraj Sanjay Kale) [Orabug: 37844459] {CVE-2025-22102}
    - iiolightopt3001修正因並行旗標存取造成的鎖死 (Luca Ceresoli) [Orabug: 37977026] {CVE-2025-37968}
    - mm/page_alloc修正未接受的記憶體處理中的爭用情形 (Kirill A. Shutemov) [Orabug: 38094767] {CVE-2025-38008}
    - dmaengineidxd使用 idxd_cleanup() 協助程式重構移除呼叫 (Shuai Xue) [Orabug: 38094790] {CVE-2025-38014}
    - dmaengineidxd修正 idxd_alloc 錯誤處理路徑中的記憶體洩漏 (Shuai Xue) [Orabug: 38094793] {CVE-2025-38015}
    - dmaengineti: k3-udma新增缺少的鎖定 (Ronald Wahl) [Orabug: 38094756] {CVE-2025-38005}
    - wifimt76移除驅動程式時停用 napi (Fedor Pchelkin) [Orabug: 38094770] {CVE-2025-38009}
    - phytegraxusb使用位元遮罩進行 UTMI pad 電源狀態追踪 (Wayne Chang) [Orabug: 38094777] {CVE-2025-38010}
    - drm/amdgpucsa 取消對應使用不中斷的鎖定 (Philip Yang) [Orabug: 38094779] {CVE-2025-38011}
    - HIDbpf如果裝置遭到損毀則中止分派 (Rongrong) [Orabug: 38094796] {CVE-2025-38016}
    - sched_extbpf_iter_scx_dsq_new() 應一律初始化 iterator (Tejun Heo) [Orabug: 38094786] {CVE-2025-38012}
    - net/tls修正 alloc_page 失敗時發生的核心錯誤 (Pengtao He) [Orabug: 38094802] {CVE-2025-38018}
    - mlxswspectrum_router刪除 GRE 網路裝置時修正釋放後使用 (Ido Schimmel) [Orabug:
    38094804] {CVE-2025-38019}
    - wifi: mac80211配置 struct cfg80211_scan_request 後設定 n_channels (Kees Cook) [Orabug:
    38094788] {CVE-2025-38013}
    -ulatormax20086修正無效的記憶體存取 (Cosmin Tanislav) [Orabug: 38094833] {CVE-2025-38027}
    - net/mlx5e停用上傳連結代表設定檔的 MACsec 卸載 (Carolina Jubran) [Orabug: 38094808] {CVE-2025-38020}
    - net_sched在 ->change() 期間也排清 gso_skb 清單 (Cong Wang) [Orabug: 37998128] {CVE-2025-37992}
    - RDMA/核心修正「KASAN: slab-use-after-free Read in ib_register_device」問題 (Zhu Yanjun) [Orabug:
    38094813] {CVE-2025-38022}
    - nfs處理解除鎖定路徑中的 nfs_get_lock_context 失敗 (Li Lingfeng) [Orabug: 38094818] {CVE-2025-38023}
    - HIDuclogic在 uclogic_input_configured() 中新增 NULL 檢查 (Henry Martin) [Orabug: 38094764] {CVE-2025-38007}
    - RDMA/rxe修正 rxe_queue_cleanup 錯誤中的 slab-use-after-free Read (Zhu Yanjun) [Orabug38094827] {CVE-2025-38024}
    - arm64bpf僅緩解無權限使用者載入的 cBPF 程式 (James Morse) [Orabug: 37977004] {CVE-2025-37963}
    - arm64bpf將 BHB 緩解措施新增至 cBPF 程式的結尾 (James Morse) [Orabug: 37976926] {CVE-2025-37948}
    - usbtypecucsi: displayport修正 NULL 指標存取 (Andrei Kuzynski) [Orabug: 38015126] {CVE-2025-37994}
    - module確保 kobject_put() 對於模組類型 kobjects 是安全的 (Dmitry Antipov) [Orabug: 38015131] {CVE-2025-37995}
    - memblock在 memblock_double_array() 中使用前接受配置的記憶體 (Tom Lendacky) [Orabug:
    37976994] {CVE-2025-37960}
    - xenbus使用 kref 追踪 req 存留期 (Jason Andryuk) [Orabug: 37976934] {CVE-2025-37949}
    - smbclient避免租用中斷在 open_cached_dir 中發生爭用 (Paul Aurich) [Orabug: 37976959] {CVE-2025-37954}
    - drm/amd/display修正 dml 協助程式中的無效內容錯誤 (Roman Li) [Orabug: 37977185] {CVE-2025-37965}
    - drm/v3d如果略過重設則新增工作至擱置清單 (Maira Canal) [Orabug: 37976942] {CVE-2025-37951}
    - iio: imu: st_lsm6dsx修正 st_lsm6dsx_read_tugged_fifo 中可能的鎖定 (Silvano Seva) [Orabug:
    37977031] {CVE-2025-37969}
    - iioimu st_lsm6dsx修正 st_lsm6dsx_read_fifo 中可能的鎖定 (Silvano Seva) [Orabug: 37977037] {CVE-2025-37970}
    - KVMSVM在 SHUTDOWN 攔截時強制離開 SMM 模式 (Mikhail Lobanov) [Orabug: 37976977] {CVE-2025-37957}
    - mm/huge_memory修正無效的 pmd 移轉項目解除參照 (Gavin Guo) [Orabug: 37976982] {CVE-2025-37958}
    - x86/mm消除可能會意外略過 TLB 排清的視窗 (Dave Hansen) [Orabug: 37977013] {CVE-2025-37964}
    - stagingbcm2835-camera初始化 v4l2_dev 中的 dev (Dave Stevenson) [Orabug: 37977042] {CVE-2025-37971}
    - Input: mtk-pmic-keys - 修正可能的 null 指標解除參照 (Gary Bisson) [Orabug: 37977044] {CVE-2025-37972}
    - bpf在 bpf_redirect_peer 上抹除封包 (Paul Chaignon) [Orabug: 37976990] {CVE-2025-37959}
    - netfilteripset修正雜湊類型中的區域鎖定 (Jozsef Kadlecsik) [Orabug: 38015141] {CVE-2025-37997}
    - ipvs修正 do_output_route4 中 saddr 的 uninit-value (Julian Anastasov) [Orabug: 37976996] {CVE-2025-37961}
    - canm_canm_can_class_allocate_dev()初始化裝置探查上的微調鎖定 (Antonios Salios) [Orabug
    38015123] {CVE-2025-37993}
    - virtio-net在 virtnet_xsk_pool_enable() 中發生錯誤時釋放 xsk_buffs (Jakub Kicinski) [Orabug: 37976969] {CVE-2025-37955}
    - sch_htb使 htb_deactivate() 等冪 (Cong Wang) [Orabug: 37977176] {CVE-2025-37953}
    - ksmbd修正 parse_lease_state() 中的記憶體洩漏 (Zhaolong Wang) [Orabug: 37977180] {CVE-2025-37962}
    - openvswitch修正 output_userspace() 中不安全的屬性剖析 (Eelco Chaudron) [Orabug: 38015148] {CVE-2025-37998}
    - ksmbd修正 __close_file_table_ids 中的 UAF (Sean Heelan) [Orabug: 37976951] {CVE-2025-37952}
    - ksmbd透過驗證 *pos 來防止越界資料流寫入 (Norbert Szetei) [Orabug: 37976923] {CVE-2025-37947}
    - ksmbd防止使用空白字串重新命名 (Namjae Jeon) [Orabug: 37976972] {CVE-2025-37956}
    - s390/pci當 PF 具有子 VF 時在 disable_slot() 中修正重複的 pci_dev_put() (Niklas Schnelle) [Orabug:
    37976920] {CVE-2025-37946}
    - wificfg80211修正多重連結元素重組期間的超出邊界存取 (Veerendranath Jakkam) [Orabug: 37977046] {CVE-2025-37973}
    - s390/pci修正遺漏的 zpci_create_device() 錯誤傳回檢查 (Niklas Schnelle) [Orabug: 37977050] {CVE-2025-37974}
    - fs/erofs/fileio在 bio_add_folio() 之後呼叫 erofs_onlinefolio_split() (Max Kellermann) [Orabug:
    38015155] {CVE-2025-37999}
    - mlxbf-bootctl在 secure_boot_fuse_state_show() 中使用 sysfs_emit_at() (David Thompson) [Orabug:
    37964051,38037120] {CVE-2025-37866}

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

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
252244	Oracle Linux 10 / 9Unbreakable Enterprise 核心 (ELSA-2025-20530)	Nessus	Oracle Linux Local Security Checks	2025/8/19	2026/2/9	medium
360579	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc多個弱點（ALMALINUX9.2：CLSA-2026：1767864313）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
231027	Linux Distros 未修補弱點：CVE-2024-53207	Nessus	Misc.	2025/3/6	2026/8/5	medium
216985	Debian dla-4076：linux-config-6.1 - 安全性更新	Nessus	Debian Local Security Checks	2025/3/1	2026/1/6	high
242347	Oracle Linux 9：Unbreakable Enterprise 核心 (ELSA-2025-20480)	Nessus	Oracle Linux Local Security Checks	2025/7/18	2026/2/9	medium

偵測

搜尋 Plugin

medium

high

medium

high

medium