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

  - drm/i915修正錯誤擷取和 debugfs 轉儲存期間的要求參照計數。當 GuC 支援新增至錯誤擷取時要求物件的參照計數會損毀。修正。內容型搜尋可在內部管理有關搜尋的執行緒同步鎖定。因此它也需要在內部取得參照計數。execlist only 要求型搜尋依賴外部鎖定因此它需要外部參照計數但在執行緒同步鎖定之內而不是在其外部。其他唯一的內容搜尋呼叫者是將引擎狀態轉儲存至 debugfs 的程式碼。該程式碼先前並未取得明確參照因為它會在保留 execlist 特定執行緒同步鎖定的同時執行所有作業。因此這需要更新以及在使用 GuC 提交時執行緒同步鎖定沒有幫助。與其嘗試依提交模型有條件的 get/put 不如將其變更為一律執行 get/put。 v2明確記錄在某些密集程式碼中新增的額外空白行 (Andy Shevchenko)。修正在未找到要求的情況下可能發生的多個 null 指標解除參照 (部分是由 Tvrtko 發現但還有更多)。此外也修正 !started 和 __guc_reset_context 中另一個因 intel_context_find_active_request 實際上是針對傳回的要求進行參照計數而導致的洩漏要求。 v3新增 _get suffix 至 intel_context_find_active_request 現在其可擷取參照 (Daniele)。 v4：將 intel_guc_find_hung_context 變更分割為獨立的修補程式並將 intel_context_find_active_request_get 重新命名為 intel_context_get_active_request (Tvrtko)。 v5
    認可訊息 (Tvrtko) 中的 s/locking/reference accounting/ (從認可 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec) (CVE-2023-52981)

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

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

  - 已解決 Linux 核心中的下列弱點：phy: mdio: fix memory leak Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. (CVE-2021-47416)

  - 在 Linux 核心的 TeleTYpe 子系統中發現超出邊界讀取缺陷。由於 flush_to_ldisc 函式中存在記憶體洩漏弱點，使用者利用 ioctls 的 TIOCSPTLCK、TIOCGPTPEER、TIOCSTI 和 TCXONC 觸發爭用情形時會發生此問題。本機使用者可利用此缺陷造成系統當機，或從記憶體讀取未經授權的隨機資料。(CVE-2022-1462)

  - 已解決 Linux 核心中的下列弱點：can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - 已解決 Linux 核心中的下列弱點：tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ----
    ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key);
    lock(&port->lock); lock(console_owner); As commit dbdda842fe96 (printk: Add console owner and waiter logic to load balance console writes) said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted
    ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock:
    ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
    tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key);
    call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
    vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated--- (CVE-2022-49441)

  - 已解決 Linux 核心中的下列弱點：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

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

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

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

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

    ovl針對 memcpy() 目的地使用 buf 彈性陣列 (CVE-2022-49743)

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

    mm/uffd修正 fork() 無分支事件時的 pte 標記 (CVE-2022-49744)

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

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

    在 Linux 核心的 Framebuffer Console (fbcon) 中發現一個缺陷。為 fbcon_set_font 提供大於 32 的 font->width 和 font->height 時，由於沒有適當的檢查，會發生移位超出邊界，進而導致未定義的行為且可能造成拒絕服務。(CVE-2023-3161)

    drivers/nvmem/brcm_nvram.c 中的 brcm_nvram_parse 未檢查 kzalloc() 的傳回值，這會造成 NULL 指標解除參照 (CVE-2023-3359)

    在 Linux 核心的 vc_screen 中，發現 drivers/tty/vt/vc_screen.c 的 vcs_read 中存在釋放後使用瑕疵。具有本機使用者存取權的攻擊者可利用此瑕疵，來造成系統當機或洩漏核心內部資訊。(CVE-2023-3567)

    在 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 核心中，下列弱點已解決：

    bpf略過 backtrack_insn 中的無效 kfunc 呼叫 (CVE-2023-52928)

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

    drm/i915修正可能發生的 bit_17 重複釋放 (CVE-2023-52930)

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

    drm/i915避免潛在的 vm 釋放後使用 (CVE-2023-52931)

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

    mm/swapfile: 在 get_swap_pages() 中新增 cond_resched() (CVE-2023-52932)

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

    Squashfs: 修復 xattr_ids 數量處理和功能健全檢查的錯誤 (CVE-2023-52933)

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

    mm/MADV_COLLAPSE捕捉 !none !huge !bad pmd 查閱 (CVE-2023-52934)

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

    mm/khugepaged修正 ->anon_vma 爭用 (CVE-2023-52935)

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

    kernel/irq/irqdomain.c透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-52936)

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

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

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

    mmmemcg修正 mem_cgroup_track_foreign_dirty_slowpath() 中的 NULL 指標 (CVE-2023-52939)

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

    mm多代 LRU修正 cgroup 移轉期間發生的當機 (CVE-2023-52940)

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

    cgroup/cpuset修正 update_parent_subparts_cpumask() 中的錯誤檢查 (CVE-2023-52942)

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

    vc_screen：移動 vcs_read() 中的 struct vc_data 指標載入以避免 UAF (CVE-2023-52973)

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

    efi修正 efi_mem_reserve_persistent 中潛在的 NULL 解除參照 (CVE-2023-52976)

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

    net: openvswitch: 修復 ovs_flow_cmd_new 中的流程記憶體流失 (CVE-2023-52977)

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

    squashfs: 強化 squashfs_read_xattr_id_table 中的功能健全檢查 (CVE-2023-52979)

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

    drm/i915修正錯誤擷取和 debugfs 轉儲存期間的要求參照計數 (CVE-2023-52981)

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

    fscache使用 wait_on_bit() 來等待釋放的放棄磁碟區 (CVE-2023-52982)

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

    block、bfq修正 bic_set_bfqq() 中 bfqq 的 uaf (CVE-2023-52983)

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

    bpf、sockmap複製接聽程式時檢查任何 tcp_bpf_prots (CVE-2023-52986)

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

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
248938	Linux Distros 未修補的弱點：CVE-2023-52981	Nessus	Misc.	2025/8/12	2026/9/30	medium
352871	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1783791447）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/1	medium
173140	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-132)	Nessus	Amazon Linux Local Security Checks	2023/3/21	2026/2/24	high

偵測

搜尋 Plugin

medium

medium

high