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

  - net： bridge： mcast：修正主要 VLAN 多點傳播內容的釋放後使用 br_multicast_toggle_one_vlan（） 在停止 VLAN 的多點傳播內容之前清除 br->multicast_lock 下的BR_VLFLAG_MCAST_ENABLED。這就是拆解握手：無鎖讀者通過 br_multicast_ctx_should_use（） -> br_multicast_ctx_vlan_disabled（） 對旗幟進行門禁，因此一旦它在鎖下被清除，任何讀者都無法再次武裝上下文。對於主 VLAN，交握永遠不會執行。__vlan_del（） 會在呼叫 br_vlan_put_master（） 之前清除BRIDGE_VLAN_INFO_BRENTRY，因此 br_multicast_toggle_one_vlan（masterv， false） 會在 ！br_vlan_is_brentry（vlan） 早期返回：旗標保持設定狀態，並且永遠不會採用 br->multicast_lock。然後，br_vlan_put_master（） 會耗盡 br_multicast_ctx_deinit（） 中的上下文，並透過 call_rcu（） 釋放 VLAN，而仍在 rcu_read_lock（） 內的讀取器會將上下文視為已啟用並重新武裝它。函式的 port 和 port-VLAN 分支沒有 br_vlan_is_brentry（） 測試，並在 br->multicast_lock 下翻轉旗標，因此不受影響。讀取器是橋接傳輸路徑。對於主 VLAN br_multicast_rcv（） 選擇 brmctx = &vlan->br_mcast_ctx 且 pmctx = NULL，因此傳送到橋接裝置的 IGMP 會在 br_multicast_ctx_deinit（） 已經停止上下文的計時器後重新布防它們。錯誤：KASAN：detach_if_pending+0x412/0x4a0 中的 slab-use-after-free 透過任務 brmc/601 在 addr ffff88810ac39918 寫入大小 8
    __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 由任務 610 分配：br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 由任務 0 釋放：kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 啟用時僅測試 br_vlan_is_brentry（） 就像旁邊的 br_multicast_ctx_vlan_global_disabled（） 測試一樣。然後，停用總是會在 br_multicast_ctx_deinit（） 耗盡上下文之前清除 br->multicast_lock 下的BR_VLFLAG_MCAST_ENABLED。
    (CVE-2026-80842)

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

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

    - Bonaccorso debian-lts@lists.debian.org------------------------------------------------------------------------- https://www.debian.org/lts/security/Salvatore Debian LTS 公告 DLA-4777-1 2026 年 9 月 8 日https://wiki.debian.org/LTS
    - -------------------------------------------------------------------------

    套件：linux 版本： 6.1.187-1 CVE ID： CVE-2023-53706 CVE-2023-54141 CVE-2023-54263 CVE-2024-38620 CVE-2024-46754 CVE-2024-58094 CVE-2024-58095 CVE-2025-22104 CVE-2025-38117 CVE-2025-38203 CVE-2025-38206 CVE-2025-38237 CVE-2025-38616 CVE-2025-39833 CVE-2025-39901 CVE-2025-39925 CVE-2025-40054 CVE-2025-40064 CVE-2025-40102 CVE-2025-40139 CVE-2025-40168 CVE-2025-40206 CVE-2025-40307 CVE-2025-68794 CVE-2026-23394 CVE-2026-31419 CVE-2026-43491 CVE-2026-45963 CVE-2026-46111 CVE-2026-46158 CVE-2026-46170 CVE-2026-46266 CVE-2026-53089 CVE-2026-53090 CVE-2026-53361 CVE-2026-64082 CVE-2026-64139 CVE-2026-64192 CVE-2026-64270 CVE-2026-64272 CVE-2026-64280 CVE-2026-64294 CVE-2026-64434 CVE-2026-64507 CVE-2026-64508 CVE-2026-64542 CVE-2026-64543 CVE-2026-64561 CVE-2026-64562 CVE-2026-64563 CVE-2026-64564 CVE-2026-64565 CVE-2026-64567 CVE-2026-64569 CVE-2026-64571 CVE-2026-64572 CVE-2026-64573 CVE-2026-64576 CVE-2026-64577 CVE-2026-64578 CVE-2026-64579 CVE-2026-64580 CVE-2026-64581 CVE-2026-64582 CVE-2026-64583 CVE-2026-64584 CVE-2026-64586 CVE-2026-64590 CVE-2026-68082 CVE-2026-68093 CVE-2026-68096 CVE-2026-68099 CVE-2026-68100 CVE-2026-68104 CVE-2026-68106 CVE-2026-68108 CVE-2026-68111 CVE-2026-68115 CVE-2026-68117 CVE-2026-68121 CVE-2026-68123 CVE-2026-68124 CVE-2026-68125 CVE-2026-68127 CVE-2026-68129 CVE-2026-68130 CVE-2026-68131 CVE-2026-68132 CVE-2026-68135 CVE-2026-68136 CVE-2026-68137 CVE-2026-68138 CVE-2026-68140 CVE-2026-68141 CVE-2026-68142 CVE-2026-68143 CVE-2026-68144 CVE-2026-68146 CVE-2026-68147 CVE-2026-68148 CVE-2026-68151 CVE-2026-68153 CVE-2026-68154 CVE-2026-68155 CVE-2026-68156 CVE-2026-68157 CVE-2026-68158 CVE-2026-68159 CVE-2026-68160 CVE-2026-68162 CVE-2026-68164 CVE-2026-68165 CVE-2026-68169 CVE-2026-68175 CVE-2026-68176 CVE-2026-68180 CVE-2026-68181 CVE-2026-68182 CVE-2026-68183 CVE-2026-68184 CVE-2026-68186 CVE-2026-68187 CVE-2026-68188 CVE-2026-68189 CVE-2026-68190 CVE-2026-68192 CVE-2026-68194 CVE-2026-68195 CVE-2026-68196 CVE-2026-68197 CVE-2026-68198 CVE-2026-68199 CVE-2026-68202 CVE-2026-68204 CVE-2026-68206 CVE-2026-68207 CVE-2026-68209 CVE-2026-68210 CVE-2026-68212 CVE-2026-68213 CVE-2026-68214 CVE-2026-68215 CVE-2026-68216 CVE-2026-68217 CVE-2026-68218 CVE-2026-68222 CVE-2026-68223 CVE-2026-68226 CVE-2026-68227 CVE-2026-68229 CVE-2026-68231 CVE-2026-68234 CVE-2026-68243 CVE-2026-68244 CVE-2026-68246 CVE-2026-68248 CVE-2026-68249 CVE-2026-68250 CVE-2026-68251 CVE-2026-68253 CVE-2026-68254 CVE-2026-68255 CVE-2026-68259 CVE-2026-68269 CVE-2026-68277 CVE-2026-68278 CVE-2026-68279 CVE-2026-68280 CVE-2026-68284 CVE-2026-68294 CVE-2026-68297 CVE-2026-68299 CVE-2026-68300 CVE-2026-68301 CVE-2026-68302 CVE-2026-68304 CVE-2026-68309 CVE-2026-68310 CVE-2026-68313 CVE-2026-68315 CVE-2026-68320 CVE-2026-68322 CVE-2026-68324 CVE-2026-68325 CVE-2026-68326 CVE-2026-68327 CVE-2026-68328 CVE-2026-68331 CVE-2026-68333 CVE-2026-68335 CVE-2026-68336 CVE-2026-68338 CVE-2026-68340 CVE-2026-68343 CVE-2026-68344 CVE-2026-68349 CVE-2026-68350 CVE-2026-68351 CVE-2026-68352 CVE-2026-68353 CVE-2026-68354 CVE-2026-68355 CVE-2026-68357 CVE-2026-68359 CVE-2026-68360 CVE-2026-68361 CVE-2026-68362 CVE-2026-68363 CVE-2026-68365 CVE-2026-68366 CVE-2026-68367 CVE-2026-68368 CVE-2026-68369 CVE-2026-68370 CVE-2026-68371 CVE-2026-68373 CVE-2026-68376 CVE-2026-68377 CVE-2026-68386 CVE-2026-68388 CVE-2026-68395 CVE-2026-68397 CVE-2026-68398 CVE-2026-68402 CVE-2026-68403 CVE-2026-68405 CVE-2026-68406 CVE-2026-68407 CVE-2026-68410 CVE-2026-68411 CVE-2026-68413 CVE-2026-68414 CVE-2026-68417 CVE-2026-68422 CVE-2026-68425 CVE-2026-68427 CVE-2026-68428 CVE-2026-68430 CVE-2026-68431 CVE-2026-68432 CVE-2026-68433 CVE-2026-68434 CVE-2026-68444 CVE-2026-68446 CVE-2026-68450 CVE-2026-68451 CVE-2026-68452 CVE-2026-68476 CVE-2026-68480 CVE-2026-72012 CVE-2026-72015 CVE-2026-72017 CVE-2026-72023 CVE-2026-72030 CVE-2026-72035 CVE-2026-72040 CVE-2026-72041 CVE-2026-72045 CVE-2026-72051 CVE-2026-72057 CVE-2026-72062 CVE-2026-72063 CVE-2026-72065 CVE-2026-72069 CVE-2026-72070 CVE-2026-72077 CVE-2026-72096 CVE-2026-72099 CVE-2026-72110 CVE-2026-72113 CVE-2026-72114 CVE-2026-72115 CVE-2026-72116 CVE-2026-72117 CVE-2026-72118 CVE-2026-72119 CVE-2026-72121 CVE-2026-72124 CVE-2026-72125 CVE-2026-72142 CVE-2026-72146 CVE-2026-72157 CVE-2026-72170 CVE-2026-72172 CVE-2026-72191 CVE-2026-72216 CVE-2026-72236 CVE-2026-72237 CVE-2026-72242 CVE-2026-72252 CVE-2026-72253 CVE-2026-72260 CVE-2026-72262 CVE-2026-72299 CVE-2026-72305 CVE-2026-72308 CVE-2026-72323 CVE-2026-72392 CVE-2026-74436 CVE-2026-74441 CVE-2026-74443 CVE-2026-74444 CVE-2026-74446 CVE-2026-74450 CVE-2026-74453 CVE-2026-74454 CVE-2026-74455 CVE-2026-74456 CVE-2026-74457 CVE-2026-74458 CVE-2026-74459 CVE-2026-74460 CVE-2026-74461 CVE-2026-74463 CVE-2026-74464 CVE-2026-74465 CVE-2026-74467 CVE-2026-74468 CVE-2026-74469 CVE-2026-74470 CVE-2026-74471 CVE-2026-74472 CVE-2026-74473 CVE-2026-74475 CVE-2026-74476 CVE-2026-74478 CVE-2026-74479 CVE-2026-74480 CVE-2026-74481 CVE-2026-74482 CVE-2026-74485 CVE-2026-74487 CVE-2026-74488 CVE-2026-74490 CVE-2026-74492 CVE-2026-74493 CVE-2026-74494 CVE-2026-74495 CVE-2026-74497 CVE-2026-74498 CVE-2026-74499 CVE-2026-74505 CVE-2026-74507 CVE-2026-74508 CVE-2026-74509 CVE-2026-74510 CVE-2026-74512 CVE-2026-74514 CVE-2026-74515 CVE-2026-74516 CVE-2026-74518 CVE-2026-74519 CVE-2026-74522 CVE-2026-74523 CVE-2026-74525 CVE-2026-74540 CVE-2026-74546 CVE-2026-74547 CVE-2026-74548 CVE-2026-74549 CVE-2026-74550 CVE-2026-74551 CVE-2026-74552 CVE-2026-74553 CVE-2026-74555 CVE-2026-74556 CVE-2026-74557 CVE-2026-74563 CVE-2026-74564 CVE-2026-74566 CVE-2026-74567 CVE-2026-74569 CVE-2026-74575 CVE-2026-74577 CVE-2026-74579 CVE-2026-74580 CVE-2026-74581 CVE-2026-74582 CVE-2026-74583 CVE-2026-74585 CVE-2026-74586 CVE-2026-74587 CVE-2026-74588 CVE-2026-74589 CVE-2026-74594 CVE-2026-74595 CVE-2026-74597 CVE-2026-74598 CVE-2026-74601 CVE-2026-74603 CVE-2026-74604 CVE-2026-74607 CVE-2026-74608 CVE-2026-74609 CVE-2026-74612 CVE-2026-74613 CVE-2026-74614 CVE-2026-74615 CVE-2026-74616 CVE-2026-74620 CVE-2026-74621 CVE-2026-74622 CVE-2026-74623 CVE-2026-74624 CVE-2026-74625 CVE-2026-74626 CVE-2026-74628 CVE-2026-74630 CVE-2026-74631 CVE-2026-74632 CVE-2026-74635 CVE-2026-74636 CVE-2026-74637 CVE-2026-74641 CVE-2026-74647 CVE-2026-74648 CVE-2026-74649 CVE-2026-74650 CVE-2026-74651 CVE-2026-74654 CVE-2026-74656 CVE-2026-74657 CVE-2026-74658 CVE-2026-74659 CVE-2026-74660 CVE-2026-74662 CVE-2026-74663 CVE-2026-74664 CVE-2026-74666 CVE-2026-74667 CVE-2026-74668 CVE-2026-74669 CVE-2026-74671 CVE-2026-74672 CVE-2026-74673 CVE-2026-74675 CVE-2026-74676 CVE-2026-74678 CVE-2026-74679 CVE-2026-74680 CVE-2026-74682 CVE-2026-74683 CVE-2026-74688 CVE-2026-74689 CVE-2026-74691 CVE-2026-74692 CVE-2026-74693 CVE-2026-74694 CVE-2026-74696 CVE-2026-74697 CVE-2026-74701 CVE-2026-74704 CVE-2026-74705 CVE-2026-74714 CVE-2026-74717 CVE-2026-74719 CVE-2026-74720 CVE-2026-74722 CVE-2026-74724 CVE-2026-74726 CVE-2026-74730 CVE-2026-74737 CVE-2026-74739 CVE-2026-74743 CVE-2026-74744 CVE-2026-74746 CVE-2026-74748 CVE-2026-80527 CVE-2026-80528 CVE-2026-80529 CVE-2026-80534 CVE-2026-80536 CVE-2026-80539 CVE-2026-80540 CVE-2026-80541 CVE-2026-80547 CVE-2026-80548 CVE-2026-80549 CVE-2026-80550 CVE-2026-80552 CVE-2026-80553 CVE-2026-80555 CVE-2026-80557 CVE-2026-80558 CVE-2026-80559 CVE-2026-80560 CVE-2026-80561 CVE-2026-80562 CVE-2026-80565 CVE-2026-80567 CVE-2026-80568 CVE-2026-80569 CVE-2026-80570 CVE-2026-80572 CVE-2026-80573 CVE-2026-80574 CVE-2026-80583 CVE-2026-80584 CVE-2026-80586 CVE-2026-80589 CVE-2026-80590 CVE-2026-80678 CVE-2026-80679 CVE-2026-80680 CVE-2026-80681 CVE-2026-80684 CVE-2026-80686 CVE-2026-80706 CVE-2026-80707 CVE-2026-80708 CVE-2026-80709 CVE-2026-80714 CVE-2026-80715 CVE-2026-80716 CVE-2026-80717 CVE-2026-80718 CVE-2026-80722 CVE-2026-80725 CVE-2026-80726 CVE-2026-80730 CVE-2026-80731 CVE-2026-80732 CVE-2026-80733 CVE-2026-80737 CVE-2026-80742 CVE-2026-80743 CVE-2026-80744 CVE-2026-80752 CVE-2026-80754 CVE-2026-80756 CVE-2026-80757 CVE-2026-80762 CVE-2026-80763 CVE-2026-80764 CVE-2026-80765 CVE-2026-80766 CVE-2026-80767 CVE-2026-80768 CVE-2026-80770 CVE-2026-80772 CVE-2026-80781 CVE-2026-80782 CVE-2026-80783 CVE-2026-80784 CVE-2026-80788 CVE-2026-80789 CVE-2026-80790 CVE-2026-80791 CVE-2026-80792 CVE-2026-80793 CVE-2026-80794 CVE-2026-80795 CVE-2026-80796 CVE-2026-80797 CVE-2026-80798 CVE-2026-80799 CVE-2026-80800 CVE-2026-80801 CVE-2026-80802 CVE-2026-80803 CVE-2026-80805 CVE-2026-80806 CVE-2026-80807 CVE-2026-80808 CVE-2026-80809 CVE-2026-80812 CVE-2026-80814 CVE-2026-80819 CVE-2026-80823 CVE-2026-80824 CVE-2026-80826 CVE-2026-80827 CVE-2026-80828 CVE-2026-80829 CVE-2026-80830 CVE-2026-80831 CVE-2026-80832 CVE-2026-80840 CVE-2026-80842 CVE-2026-80843 CVE-2026-80844 CVE-2026-80846 CVE-2026-80848 CVE-2026-80852 CVE-2026-80854 CVE-2026-80855 CVE-2026-80856 CVE-2026-80863 CVE-2026-80888 CVE-2026-80890 CVE-2026-80891 CVE-2026-80892 CVE-2026-80893 CVE-2026-80901 CVE-2026-80902 CVE-2026-80904 CVE-2026-80906 CVE-2026-80908 CVE-2026-80909 CVE-2026-80910 CVE-2026-80913

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

    對於 Debian 12 書蟲來說，這些問題已經在版本 6.1.187-1中修復了。

    建議您升級 linux 套件。

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

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

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

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

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

  - 已解決 Linux 核心中的下列弱點：dma-debug: don't call
    __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}:
    _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8
    ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8
    __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}:
    __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc
    _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key --> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock);
    lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace:
    dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated--- (CVE-2023-52516)

  - 已解決 Linux 核心中的下列弱點：USB: sisusbvga: Add endpoint checks The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver: ------------[ cut here]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU:
    1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Workqueue: usb_hub_wq hub_event RIP:
    0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95 RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000 R10:
    0000000080000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869 ... The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of the endpoints. (CVE-2023-54213)

  - 已解決 Linux 核心中的下列弱點：net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 (act_mirred: use the backlog for nested calls to mirred ingress) hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. (CVE-2024-26740)

  - 已解決 Linux 核心中的下列弱點：mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF:
    supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops:
    0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name:
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS:
    00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI:
    0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14:
    0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3:
    000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: > <TASK> > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP:
    002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08:
    0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 > </TASK> (CVE-2024-26783)

  - 已解決 Linux 核心中的下列弱點：vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(i_ea) ---- AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ubifs_jnl_write_inode ABBA deadlock -----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate(
    ---truncated--- (CVE-2024-45003)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
364137	Oracle Linux 10 / 9：Unbreakable Enterprise 核心 (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
365220	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2026-3197)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/22	medium
351155	Debian dsa-6528 ： ata-modules-6.12.111+deb13-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/9/29	2026/9/29	high
363954	Oracle Linux 8/9：Unbreakable Enterprise 核心 (ELSA-2026-500377)	Nessus	Oracle Linux Local Security Checks	2026/10/7	2026/10/7	high
365283	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3187)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/26	medium
362907	Debian dla-4817 ： ata-modules-6.12.107+deb12-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/10/4	2026/10/4	high
343039	Linux Distros 未修補弱點：CVE-2026-80842	Nessus	Misc.	2026/9/4	2026/11/6	high
343851	Debian dla-4777 ： ata-modules-6.1.0-52-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/9/8	2026/9/8	high
351051	Amazon Linux 2：kernel (ALASKERNEL-5.15-2026-116)	Nessus	Amazon Linux Local Security Checks	2026/9/29	2026/10/2	high
374135	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc多個弱點（ALMALINUX9.2：CLSA-2026：1793333110）	Nessus	Alma Linux Local Security Checks	2026/10/30	2026/11/2	high
365279	Amazon Linux 2023：bpftool6.12、kernel6.12、kernel6.12-devel （ALAS2023-2026-3196）	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/22	medium

偵測

搜尋 Plugin

high

medium

high

high

medium

high

high

high

high

high

medium