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

  - uutils coreutils 的 cp 工具中的「檢查時間到使用時間」（TOCTOU）漏洞，允許攻擊者繞過無去參照意圖。該工具會利用基於路徑的元資料檢查來源路徑是否為符號連結，但隨後在未開啟 O_NOFOLLOW 標誌的情況下開啟該連結。同時擁有寫入權限的攻擊者在此視窗內，可以將一般檔案交換成符號連結，導致特權 cp 程序將任意敏感檔案的內容複製到攻擊者控制的目的地。
    (CVE-2026-35359)

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

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

  - 藍牙：btubb：當 CVSD 流量使用透明語音設定時，SCO 替代設定表索引 btusb_work（） 透過三項查詢表將活躍 SCO 連結數映射至 USB 備用設定。目前查詢會以 data->sco_num - 1 索引 alts[]，且未先限制 sco_num 可用資料表條目數量。雖然該表僅定義最多三個 SCO 連結的替代設定，但資料>sco_num來自 hci_conn_num（）並直接使用。在索引前，將查詢限制到最後一個資料表條目，讓驅動程式持續選擇支援最高的替代設定，而不會讀取過去的替代設定[]。（CVE-2026-31497）

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

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

  - uutils coreutils 中的安裝工具在檔案安裝時容易受到「檢查時間到使用時間」（TOCTOU）競賽條件的影響。實作會先解除連結一個現有的目的檔案，然後用沒有 O_EXCL 標誌的路徑操作重新建立它。本地攻擊者可以利用解除連結與隨後建立之間的視窗，將路徑與符號連結交換，從而將特權寫入重定向，覆蓋任意系統檔案。（CVE-2026-35355）

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

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

  - uutils coreutils 中的 mv 工具在跨越不同檔案系統邊界移動時無法保留檔案所有權。該工具會退回到複製並刪除的例程，利用呼叫者的 UID/GID 而非來源的元資料來建立目標檔案。此缺陷會破壞備份與遷移，導致由特權使用者（例如root）移動的檔案意外成為root擁有者，可能導致資訊外洩或限制原有擁有者的存取權限。（CVE-2026-35351）

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

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

  - uutils coreutils chown 和 chgrp 所使用的 ChownExecutor 有缺陷，導致遞迴操作時工具會回傳錯誤的退出碼。最終的出口代碼僅由最後處理的檔案決定。如果最後一次操作成功，該指令會回傳 0，即使先前的所有權或群組變更因權限錯誤失敗。這可能導致安全設定錯誤，管理腳本錯誤地假設所有權已成功跨越目錄樹。
    (CVE-2026-35340)

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

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

  - uutils coreutils 的 ln 公用程式中的邏輯錯誤會導致程式在使用目標目錄形式時拒絕包含非 UTF-8 檔案名位元組的來源路徑 （例如，ln SOURCE... 目錄）。雖然 GNU ln 將檔案名視為原始位元組並正確建立連結，但 uutils 實作強制執行 UTF-8 編碼，導致無法統計檔案和非零退出代碼。在自動化指令碼或系統任務處理 Unix 檔案系統上常見的有效但非 UTF-8 檔案名稱的環境中，這種差異會導致公用程式失敗，進而導致這些特定作業的本機拒絕服務。
    (CVE-2026-35373)

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

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

  - perf：確保對群組使用 pmu_ctx->pmu Oliver 報告說，當 group_sched_in（） 失敗並需要復原時，x86_pmu_del（） 最終會執行越界記憶體存取。這*應該*由事務回呼來處理，但他發現，當組長是軟體事件時，會使用錯誤 PMU 的事務處理常式。儘管在 perf_event_open（） 和 group_sched_in（） 中使用 pmu_ctx->pmu 的move_group情況。事實證明，inherit 使用 event->pmu 來複製事件，有效地還原所有繼承上下文的move_group情況。藉由使繼承使用pmu_ctx->pmu 來修正此問題，以確保所有繼承的計數器最終都位於相同的 pmu 內容中。同樣地，__perf_event_read（） 應該同樣地使用pmu_ctx->pmu 來處理群組大小寫。（CVE-2026-31528）

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

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

  - net修正 packet_release() 中透過 NETDEV_UP 爭用的 fanout UAF「packet_release()」有爭用期間「NETDEV_UP」可將通訊端重新註冊到 fanout 群組的「arr[]」陣列中。`fanout_release()` 未清除重新註冊而在 fanout 陣列中留下懸置指標。 「packet_release()」不會在其「bind_lock」區段中歸零「po->num」。釋放 `bind_lock` 後`po->num` 仍為非零且 `po->ifindex` 仍符合系結裝置。已在 `sklist` 中找到通訊端的並行 `packet_notifier(NETDEV_UP)` 可重新註冊該勾點。針對 fanout 通訊端此重新註冊會呼叫 `__fanout_link(sk, po)`其會將通訊端新增回 `f->arr[]` 並遞增 `f->num_members`但不會遞增 `f->sk_ref` 。此修正在保留 `bind_lock` 時會將 `packet_release` 中的 `po->num` 設為零以防止 NETDEV_UP 連結進而防止爭用視窗。以 CVE-2025-38617為基礎使用 Claude 程式碼進行額外稽核後發現此錯誤。 (CVE-2026-31504)

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

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

  - btrfs：在 subvol 建立時設定 BTRFS_ROOT_ORPHAN_CLEANUP 我們最近觀察到多個子卷齒裂。ls-化父 dir 的做法如下：drwxrwxrwt 1 根根 16 January 23 16:49 . drwxr-x-x 1 根根 24 January 23 16:48 .. d????????? ? ? ? ? ? broken_subvol 同樣地，stat 化檔案失敗。在這種情況下，刪除 subvol 在 ENOENT 會失敗，但嘗試在 EEXIST 上建立新檔案或 subvol 時會出錯，甚至會中止 fs。這讓我們有點卡住了。DMESG 包含一個顯著錯誤訊息：無法做到孤兒清理 -2 是 ENOENT，錯誤來自故障處理路徑 btrfs_orphan_cleanup（），堆疊回溯至 btrfs_lookup（）。btrfs_lookup btrfs_lookup_dentry btrfs_orphan_cleanup // 列印該訊息並回傳
    -ENOENT 經過對內部狀態的詳細檢視後，很明顯：- 子卷沒有孤兒項目 - 子卷看起來健康，沒有半刪除，沒有掉入進度等等 - 子卷是建立在一段時間前，並且會進行有意義的第一次 btrfs_orphan_cleanup（） 呼叫，設定BTRFS_ROOT_ORPHAN_CLEANUP 很晚。- btrfs_orphan_cleanup（） 失敗後，btrfs_lookup_dentry（） 回傳 -ENOENT，導致子卷經由 d_splice_alias（NULL， dentry）產生負 dentry，導致觀察到的行為。這個錯誤可以透過丟棄 dentry 快取來緩解，屆時如果想的話，可以成功刪除子磁碟。即 btrfs_lookup（） btrfs_lookup_dentry（） 如果 （！sb_rdonly（inode->vfs_inode）->vfs_inode） btrfs_orphan_cleanup（sub_root） test_and_set_bit（BTRFS_ROOT_ORPHAN_CLEANUP） btrfs_search_slot（） // 找到 inode N 的孤兒項目 ...
    若 （inode == ERR_PTR（-ENOENT）） inode = NULL;回傳 d_splice_alias（NULL， dentry） // NEGATIVE DENTRY 對有效子卷 btrfs_orphan_cleanup（） 執行時會在根節點執行 test_and_set_bit（BTRFS_ROOT_ORPHAN_CLEANUP），因此在同一根節點上不能執行超過一次，必須同時執行其他東西。然而，當 nlink 趨近 0 時刪除孤兒的明顯路徑，不應該在不先查詢子卷前執行，該子卷應該執行 btrfs_orphan_cleanup（） 並設定位元。最後一個重要的觀察是，create_subvol（） 呼叫 d_instantiate_new（），但不會設定 BTRFS_ROOT_ORPHAN_CLEANUP，因此如果 dentry 快取被丟棄，下一次查詢子卷時會首次真正呼叫 btrfs_orphan_cleanup（）。
    這開啟了同時刪除 inode/孤兒項目的可能性，但大多數典型的 evict（） 路徑會持有父條的參考（子 dentry 透過 dget 在 d_alloc（） 中持有 parent->d_lockref.count，在 __dentry_kill（））中釋放），並防止父節點從 dentry 快取中移除。唯一的例外是延遲輸入。有序範圍建立時會在 inode 上呼叫 igrab（）。如果檔案在這些參考被保留期間解除連結並關閉，__dentry_kill（） 中的 iput（） 會減少 i_count，但不會觸發驅逐（i_count > 0）。子 dentry 被釋放，subvol 的 d_lockref.count 降到 0，使其在 inode 仍然存活時可被驅逐。由於有兩個種族（寫回與取消連結的競爭，以及查找與延遲輸入之間的競爭），且運作部件太多，以下三個圖表展示了完整的圖像。（只有第二和第三個是種族）第一階段：在 dentry 快取中建立 Subvol，但沒有設定 BTRFS_ROOT_ORPHAN_CLEANUP btrfs_mksubvol（） lookup_one_len（）
    __lookup_slow（） d_alloc_parallel（） __d_alloc（） // d_lockref.count = 1 create_subvol（dentry） // 不碰到這個位元..d_instantiate_new（dentry， inode） // 快取中的 dentry 與 d_lockref.c ---truncated--- （CVE-2026-31519）

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

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

  - ksmbd：不會在綁定失敗時使工作階段過期 當多通道工作階段綁定要求失敗時 （例如
    錯誤密碼），錯誤路徑無條件設定 sess->state = SMB2_SESSION_EXPIRED。但是，在綁定期間，sess 指向透過 ksmbd_session_lookup_slowpath（） 查詢的目標工作階段，該工作階段屬於另一個連線的使用者。這允許遠端攻擊者只需發送具有錯誤密碼 （DoS） 的綁定請求，即可使任何活動工作階段失效。當失敗的要求是繫結嘗試時，請跳過會話到期來修正此問題，因為工作階段不屬於目前連線。ksmbd_session_lookup_slowpath（） 所取得的參照仍會透過 ksmbd_user_session_put（） 正確釋放。（CVE-2026-31476）

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

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

  - uutils coreutils 中的 mv 工具在跨檔案系統邊界移動時，錯誤處理包含符號連結的目錄樹。實作不是保留符號連結，而是擴展它們，將連結目標複製為目的地的真實檔案或目錄。若符號連結指向大型外部目錄，可能導致資源耗盡（磁碟空間或時間）、敏感資料意外重複至非預期位置，或在符號連結迴圈存在下無限遞迴與重複複製。（CVE-2026-35365）

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

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

  - 已解決 Linux 核心中的下列弱點：Bluetooth: L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req Syzbot reported a KASAN stack-out-of-bounds read in l2cap_build_cmd() that is triggered by a malformed Enhanced Credit Based Connection Request. The vulnerability stems from l2cap_ecred_conn_req(). The function allocates a local stack buffer (`pdu`) designed to hold a maximum of 5 Source Channel IDs (SCIDs), totaling 18 bytes. When an attacker sends a request with more than 5 SCIDs, the function calculates `rsp_len` based on this unvalidated `cmd_len` before checking if the number of SCIDs exceeds L2CAP_ECRED_MAX_CID. If the SCID count is too high, the function correctly jumps to the `response` label to reject the packet, but `rsp_len` retains the attacker's oversized value. Consequently, l2cap_send_cmd() is instructed to read past the end of the 18-byte `pdu` buffer, triggering a KASAN panic.
    Fix this by moving the assignment of `rsp_len` to after the `num_scid` boundary check. If the packet is rejected, `rsp_len` will safely remain 0, and the error response will only read the 8-byte base header from the stack. (CVE-2026-31513)

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

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

  - uutils coreutils 中的 id 工具錯誤計算其輸出中的 groups= 區段。實作使用使用者的實際 GID 而非有效 GID 來計算群組清單，導致輸出可能與 GNU coreutils 差異。由於許多腳本與自動化流程依賴 ID 輸出來做出安全關鍵的存取控制或權限決策，這種差異可能導致未經授權的存取或安全設定錯誤。（CVE-2026-35370）

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

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

  - netfilter： nf_conntrack_expect：透過 proc 跳過不在此 netns 中的預期 跳過不在此 netns 中的預期。類似於 e77e6ff502ea （netfilter： conntrack：不要透過 proc 轉儲其他 netns 的 conntrack 項目）。（CVE-2026-31496）

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

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

  - net: openvswitch避免在卸除作業完成前釋出 netdev 以下「修正」標籤中所述的修補程式已將 OVS 連接埠的卸除程式碼變更為不再無條件採用 RTNL。進行此變更後若已清除 netdev 上的 IFF_OVS_DATAPATH 旗標則 netdev_destroy() 回呼可立即進行至 call_rcu() 叫用。ovs_netdev_detach_dev() 函式會在完成取消註冊之前清除旗標且如果在清除旗標之後旗標先佔 (如 -rt 核心上所發生的情況)netdev_destroy() 可在完成取消註冊之前完成並釋放裝置。
    這會導致顯示如下所示[ 998.393867] Oops一般保護錯誤可能是針對非正式位址 0xff000000010002390000 [#1] SMP PTI [ 998.393877] CPU 42 UID0 PID 55177 Commip Kdump
    已載入 未受污染的 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] 硬體名稱Dell Inc.
    PowerEdge R740/0JMK61、BIOS 2.24.0 2025 年 3 月 27 日 [ 998.393889] RIP 0010:dev_set_promiscuity+0x8d/0xa0 [998.393901] 程式碼00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 9 [ 998.3939069 ] ] RSP0018:ffffce5864a5f6a0 EFLAGS00010246 [ 998.393912] RAXff00000000ffff89 RBX
    ffff894d0adf5a05 RCX0000000000000000 [ 998.393917] RDX 0000000000000000 RSI00000000ffffffff RDI
    ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13:
     R14ffffce5864a5f738  : 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 [ 998.393940] CR2000055df0a2a6e40 CR3000000011c7fe003 CR400000000007726f0 [998.393944] PKRU55555554 [ 998.393946] 呼叫追踪 [ 998.393949] <TASK> [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ?
    __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145]
    []sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP61b0f43324x7fa [ 998.394188] 代碼89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP002b:00007ffd7e2f7cb8 EFLAGS00000202 ORIG_RAX
    000000000000002e [ 998.394191] RAXffffffffffffffda RBX 0000000000000001 RCX 00007fad61bf4724 [998.394193] RDX 000000000000000 RSI 00007ffd7e2f7f7d20 RDI0030000]00030000 998.394194003000000300000030000
    00007ffd7e2f7d90 R080000000000000010 R09000000000000003f [ 998.394195] R10000055df11558010 R11
    0000000000000202 R12: 00007ffd7e2 ---truncated--- (CVE-2026-31508)

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

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

  - xfrm防止 policy_hthresh.work 與 netns 終止爭用 XFRM_MSG_NEWSPDINFO 要求可將每個網路工作項目 policy_hthresh.work 排入系統工作佇列。已排入佇列的回呼 xfrm_hash_rebuild() 會透過 container_of() 擷取封閉的 struct net。如果在該工作執行前移除網路命名空間相關聯的結構網路可能已釋放而 xfrm_hash_rebuild() 可能會解除參照過時記憶體。 xfrm_policy_fini() 在終止期間已排清 policy_hash_work但不會同步 policy_hthresh.work。也同步化 xfrm_policy_fini() 中的 policy_hthresh.work因此已排入佇列的工作無法比網路命名空間終止存留更長的時間也無法存取已釋放的結構網路。
    (CVE-2026-31516)

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

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

  - uutils coreutils 中的 printenv 公用程式無法顯示包含無效 UTF-8 位元組序列的環境變數。雖然 POSIX 允許環境字串中的任意位元組但 uutils 實作會以無訊息的方式略過這些項目而非列印原始位元組。此弱點允許惡意環境變數 (例如對抗 LD_PRELOAD 值) 規避系統管理員或安全性稽核工具的檢查進而可能讓程式庫插入或其他環境型攻擊無法偵測到。 (CVE-2026-35366)

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

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

  - driver core： platform：使用通用 driver_override 基礎結構 當驅動程式透過
    __driver_attach（） 時，會在未持有裝置鎖定的情況下呼叫匯流排的 match（） 回呼，因此在沒有鎖定的情況下存取 driver_override 欄位，這可能會導致 UAF。使用驅動程式核心driver_override基礎結構來修正此問題，並在內部進行適當的鎖定。請注意，從
    未保留裝置鎖定的 __driver_attach（） 是故意的。[1] （CVE-2026-31527）

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

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

  - uutils coreutils 的 tr 工具邏輯錯誤導致程式錯誤地定義了 [：graph：] 和 [:p rint：] 字元類別。實作錯誤地將 ASCII 空間字元（0x20）包含在 [：graph：] 類別中，並排除在 [:p rint：] 類別中，實際上顛倒了 POSIX 與 GNU coreutils 所建立的標準行為。當該工具被用於依賴標準字元類別語意的自動化腳本或資料清理管線時，此漏洞會導致意外的資料修改或遺失。例如，執行刪除所有圖形字元的指令，卻意圖保留空白空間，卻錯誤刪除所有 ASCII 空間，可能導致資料損壞或後續處理邏輯故障。（CVE-2026-35379）

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

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

  - uutils coreutils 中的 mknod 工具未能在設定 SELinux 上下文前建立裝置節點，無法以原子方式處理安全標籤。若標籤失敗，工具會嘗試使用 std：：fs：：remove_dir 進行清理，但無法移除裝置節點或 FIFO。這會留下錯誤標示的節點，預設上下文錯誤，可能導致本應以強制存取控制限制的裝置節點被未經授權存取。（CVE-2026-35361）

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

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

  - iavf：修正 iavf_get_ethtool_stats（） 中的越界寫入 iavf 錯誤地將 real_num_tx_queues 用於ETH_SS_STATS。由於該值可能會在運行時發生變化，因此我們應該改用 num_tx_queues。此外，iavf_get_ethtool_stats（） 使用 num_active_queues，而 iavf_get_sset_count（） 和 iavf_get_stat_strings（） 使用 real_num_tx_queues，當我們同時執行 ethtool -L 和 ethtool -S 時，這會觸發越界寫入 [1]。例如，當我們將通道從 1 更改為 8 時，執行緒 3 可以在執行緒 2 之前進行調度，並且可以在執行緒 3 中觸發越界寫入：執行緒 1 （ethtool -L） 執行緒 2（工作） 執行緒 3 （ethtool -S） iavf_set_channels（） ...iavf_alloc_queues（） -> num_active_queues = 8 iavf_schedule_finish_config（） iavf_get_sset_count（） real_num_tx_queues：1 個佇列的 1 -> 緩衝區 iavf_get_ethtool_stats（） num_active_queues：8 -> 越界！iavf_finish_config（） -> real_num_tx_queues = 8 在所有相關函式中使用不可變num_tx_queues以避免此問題。[1] 錯誤： KASAN：iavf_add_one_ethtool_stat+0x200/0x270 中的 vmalloc-out-of-bounds 透過任務 ethtool/5800 在 addr ffffc900031c9080 寫入大小 8 CPU：1 UID：0 PID：5800 通訊：ethtool 未受污染 6.19.0-enjuk-08403-g8137e3db7f1c #241 搶佔（完整） 硬體名稱：QEMU 標準電腦 （Q35 + ICH9， 2009），BIOS 1.16.3-debian-1.16.3-2 04/01/2014 呼叫追蹤： <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x180 iavf_add_one_ethtool_stat+0x200/0x270 iavf_get_ethtool_stats+0x14c/0x2e0 __dev_ethtool+0x3d0c/0x5830 dev_ethtool+0x12d/0x270 dev_ioctl+0x53c/0xe30 sock_do_ioctl+0x1a9/0x270 sock_ioctl+0x3d4/0x5e0
    __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xf3/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：
    0033：0x7f7da0e6e36d ...</TASK> 有錯誤的位址屬於從 __dev_ethtool+0x3cc9/0x5830 配置的 0xffffc900031c9000 開始的 1 頁 vmalloc 區域 有錯誤的位址屬於實體頁面： page： refcount：1 mapcount：0 mapping：0000000000000000 index：0xffff88813a013de0 pfn：0x13a013 旗標：
    0x200000000000000（node=0|zone=2） raw： 0200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001ffffffff 0000000000000000000000000000000 頁面轉儲 因為： KASAN：錯誤存取偵測 ed 有錯誤位址周圍的記憶體狀態：ffffc900031c8f80： f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000： 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080： f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100： f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180： f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 （CVE-2026-31505）

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

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

  - RDMA/efa：修正釋放後完成 ctx 的使用 在管理佇列完成處理中，如果管理命令完成時出錯，我們會從完成內容列印資料。問題是我們已經釋放了輪詢/中斷處理常式中的完成上下文，這意味著我們從未知狀態的上下文中打印數據（它可能已經被再次使用）。變更管理員提交流程，讓內容的 alloc/dealloc 對稱，並在任何可能使用內容之後呼叫 dealloc。（CVE-2026-31493）

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

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

  - uutils coreutils 中 chmod 工具的遞迴模式（-R）在處理多個檔案時錯誤處理退出碼。最終回傳價值僅由最後處理檔案的成敗決定。這讓指令即使之前的檔案遇到錯誤，例如「不允許操作」，也能回傳 0（成功）的退出碼。依賴這些退出碼的腳本可能會帶著錯誤的成功感繼續運作，而敏感檔案則保留限制或錯誤的權限。（CVE-2026-35339）

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

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

  - uutils coreutils 中的觸控公用程式在檔案建立期間容易受到 Time-of-Use 檢查時間 （TOCTOU） 爭用情形的攻擊。當公用程式識別出遺漏的路徑時，稍後會嘗試使用 File：：create（） 建立，其內部會使用 O_TRUNC。攻擊者可利用此視窗在目標路徑建立檔案或交換符號連結，導致觸控截斷現有檔案並導致永久資料遺失。（CVE-2026-35360）

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

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

  - uutils coreutils 的切割工具邏輯錯誤導致程式錯誤地將字面上的兩位元組字串「'（兩個單引號）解讀為空分隔符。實作錯誤地將此字串映射到 NUL 字元，無論是 -d（分隔符）還是 --output-delimiter 選項。此漏洞可能導致自動化腳本與資料管線中靜默的資料損毀或邏輯錯誤，因為該工具可能無意中將資料分割或連接為 NUL 位元組，而非預期的字元。（CVE-2026-35380）

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

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

  - s390/syscalls：為 syscall 派遣表新增 spectre 邊界 s390 syscall 號碼直接由使用者空間控制，但沒有 array_index_nospec（） 邊界以防止存取超過 syscall 函式指標表。（CVE-2026-31483）

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

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

  - uutils coreutils 的 cut utility 邏輯錯誤，導致該工具在同時使用 -z（null-終止）和 -d'（空分隔符）選項時忽略 -s（僅分隔）旗標。實作錯誤地將此組合路由至專門的換行-分隔符代碼路徑，該路徑未能檢查記錄抑制狀態。因此，uutils cut 會輸出整個記錄加上一個 NUL 位元組，而非抑制它。這種與 GNU coreutils 行為的差異，對於依賴 cut -s 來過濾未界定資料的自動化管線造成資料完整性風險。（CVE-2026-35381）

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

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

  - 在 uutils coreutils 的 mv 工具中存在跨裝置移動時，存在「檢查時間到使用時間」（TOCTOU）漏洞。擴展屬性（xattr）保存邏輯使用多個基於路徑的系統呼叫，為每次操作執行新的路徑至inode查詢。擁有寫入權限的本地攻擊者可利用此競賽在呼叫間交換檔案，導致目標檔案接收到不一致的安全性 xattr，如 SELinux 標籤或檔案功能。（CVE-2026-35354）

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

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

  - uutils coreutils 中的 nohup 工具會產生其預設輸出檔 nohup.out，且未明確指定受限權限。這會使檔案繼承基於 umask 的權限，通常會產生一個世界可讀的檔案（0644）。在多使用者環境中，這允許系統上的任何使用者讀取指令擷取的 stdout/stderr 輸出，可能暴露敏感資訊。此行為與 GNU coreutils 不同，後者建立 nohup.out 並以擁有者限定權限（0600）。
    (CVE-2026-35367)

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

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

  - hwmon：（pmbus/core） 使用互斥保護調節器作業 調節器作業 pmbus_regulator_get_voltage（）、pmbus_regulator_set_voltage（） 及 pmbus_regulator_list_voltage（） 會存取 PMBus 暫存器及共用資料，但不受 update_lock 互斥項保護。這可能會導致爭用條件。但是，直接將互斥保護新增至這些函式會導致鎖死，因為 pmbus_regulator_notify（） （呼叫 regulator_notifier_call_chain（）） 通常是在互斥已持有的情況下呼叫 （例如，從 pmbus_fault_handler（））。如果穩壓器回調隨後調用現在受保護的電壓函數之一，它將嘗試獲取相同的互斥。重構 pmbus_regulator_notify（） 以利用背景工作函式在互斥保護之外傳送通知。事件會以不可部分完成的形式儲存在每頁位遮罩中，並由背景工作角色處理。在監管機構註冊期間初始化背景工作角色及其相關資料，並確保在使用 devm_add_action_or_reset（） 移除裝置時取消。在此過程中，移除不必要的 linux/of.h。（CVE-2026-31486）

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

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

  - uutils coreutils mkfifo 中的一個弱點允許未經授權修改現有檔案的權限。當 mkfifo 因為目標路徑上已存在檔案而無法建立 FIFO 時，它無法終止該路徑的作業，並繼續執行後續set_permissions呼叫。
    這會導致現有檔案的權限變更為預設模式（umask 後通常為 644），可能會將敏感檔案（例如 SSH 私密金鑰）暴露給系統上的其他使用者。
    (CVE-2026-35341)

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

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

  - drm/amd/display：請勿跳過 DSC 驗證中無關的模式變更。從提交 17ce8a6907f7（drm/amd/display：在原子檢查中加入 dsc 預驗證）開始，amdgpu 在重新計算 DSC 配置時，將 CRTC 狀態mode_changed旗重置為 false，因為特定串流的時間不變。
    然而，在 MST/DSC 配置變更發生在同一 KMS 提交中，與其他（無關）模式變更發生的情況中，此說法不正確。例如，筆記型電腦的整合面板可能會根據是否安裝外接螢幕而有所不同（例如啟用或停用 HDR）。在這種情況下，插入外部 DP-MST 螢幕可能會導致整合面板的 mode_changed 旗標錯誤遺失，且其 DSC 配置在 pre_validate_dsc（） 預計算期間未改變。然而，目前 dm_update_crtc_state（） 已經為 CRTC 建立了與 DSC 無關模式變更的新串流。反過來，amdgpu_dm_commit_streams（） 永遠不會釋放舊串流，導致記憶體洩漏。amdgpu_dm_atomic_commit_tail（） 也永遠不會取得新串流的參考，當串流後來被停用時，會呈現為 use-after-free：bug： kasan： use-after-free in dc_stream_release+0x25/0x90 [amdgpu] 任務 kworker/9:9/2997 drm_mode_rmfb_work_fn 7 在 addr ffff88813d836524 以 size 4 寫入 <TASK> dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ？ dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ？ srso_alias_return_thunk+0x5/0xfbef5 ？ __virt_addr_valid+0x225/0x4e0 ？ dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ？ dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30？drm_mode_object_put.part.0+0xb1/0x130
    __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980 由於無法可靠判斷 CRTC 在 DSC 驗證時是否有無關模式變更待處理，請記得 CRTC 被標記為可能因 DSC 配置變更而受影響前的 mode_changed 旗標值。改為將mode_changed旗標重設為先前的值，pre_validate_dsc（）。（摘自提交 CC7C7121ae082B7B82891baa7280F1FF2608F22B）（CVE-2026-31488）

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

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

  - drm/amd/display：修正 amdgpu_dm 中的drm_edid洩漏 [WHAT] 連接接收器時，aconnector->drm_edid 被覆寫而沒有釋放先前的配置，導致繼續時記憶體洩漏。[怎麼做]在更新之前釋放先前的drm_edid。（從提交 52024a94e7111366141cfc5d888b2ef011f879e5 中挑選）（CVE-2026-31461）

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

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

  - uutils coreutils 中的 mktemp 工具無法正確處理空的 TMPDIR 環境變數。
    與 GNU mktemp 不同，當 TMPDIR 是空字串時，mktemp 會回退為 /tmp，uutils 實作將空字串視為有效路徑。這會導致暫存檔案建立在目前的工作目錄（CWD），而非預期的安全暫存目錄。若CWD比/tmp更寬鬆或對其他使用者開放，可能導致資訊外洩或未經授權存取臨時資料。（CVE-2026-35342）

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

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

  - drm/xe一律追踪重新對應 prev/next 在 3D 工作負載期間使用者報告命中[ 413.361679] 警告 drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe] 、 CPU#7
    vkd3d_queue/9925 [ 413.361944] CPU7 UID1000 PID9925 Commvkd3d_queue Kdump已載入但未受污染的 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy) [ 413.361949] RIP
    0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe] [ 413.362074] RSP0018:ffffd4c25c3df930 EFLAGS00010282 [413.362077] RAX0000000000000000 RBXffff8f3ee817ed10 RCX000000[0]RCX000000[0]RCX000000[ 413.3620780 ]RCX
    0000000000000000 RSI0000000000000000 RDI0000000000000000 [ 413.362079] RBPffffd4c25c3df980 R08
    0000000000000000 R090000000000000000 [ 413.362081] R100000000000000000 R110000000000000000 R12
    ffff8f41fbf99380 [ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380 [413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000 [ 413.362085] CS:
    0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0 [ 413.362088] PKRU: 55555554 [ 413.362089] Call Trace: [ 413.362092] <TASK> [413.362096] xe_vm_bind_ioctl+0xa9a /0xc60 [xe] 這似乎暗示我們為 ops unwind 重新插入的 vma 無效或與已在 vm 中插入的項目重疊。因為這是重新插入所以它應該不會無效因此之前一定有效。將可能的罪人視為已放置我們要插入 vma 的位置留下。接著如果我們在 vma 中間執行重新系結之類的動作而其中一個或兩個對應的端點已經相容我們會略過這些 vma 的重新系結並將 next/prev 設為 NULL。以及調整原始的取消對應 va 範圍以避免取消對應端點。不過如果我們觸發回溯路徑最終會得到三個 va而這兩個端點則永遠不會移除且中間的原始 va 範圍仍為縮小後的大小。如果發生此情況另一個回溯 op 需要與該範圍互動時會出現一個失敗模式而係結向量可能會發生此情況。例如如果我們需要重新插入某個項目來取代原來的 va。在此情況下va 仍然是縮小的版本因此將其移除然後重新插入時可能會與從未移除的末端重疊進而觸發類似上述的警告且使 vm 處於錯誤狀態。有了這個我們需要做兩件事情1) 停止對略過案例的上一個/下一個追踪進行核處理。
    而非依賴於在需要時檢查是否跳過 prev/next。這樣在回溯路徑上我們現在會正確移除兩端。 2) 復原回溯路徑上的取消對應 va 縮減。現在移除兩端后取消對應 va 在重新插入之前應該會擴充回原來的大小。 v2- 根據觸發此問題的實際 IGT (而非推測)更新提交訊息中的說明。- 也可針對略過的情況復原取消對應縮減。現在移除兩端后原始的取消對應 va 範圍應擴充回原始範圍。 v3- 分別追踪舊的開始/範圍。 vma_size/start() 直接使用 va 資訊。 (從認可 aec6969f75afbf4e01fd5fb5850ed3e9c27043ac) (CVE-2026-31479)

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

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

  - ksmbd：修正 smb2_lock（） 中的記憶體洩漏和 NULL 解除參照 list_del（） 在 no_check_cl 時將 smb_lock 與 lock_list 分離後，smb2_lock（） 有三個錯誤處理問題： 1） 如果 vfs_lock_file（） 在非 UNLOCK 路徑中傳回意外錯誤，則 goto out 會洩漏 smb_lock 及其群，因為 out： 處理常式只會反覆lock_list和rollback_list， 兩者都不包含分離的smb_lock。2） 如果 vfs_lock_file（） 在 UNLOCK 路徑中傳回 -ENOENT，則 goto out 洩漏smb_lock並出於相同原因 flock。傳回給Dispatcher的錯誤碼也已過時。3）在回滾路徑中，smb_flock_init（）可以在分配失敗時傳回NULL。結果會無條件地解除參照，造成核心 NULL 指標解除參照。
    新增 NULL 檢查以防止損毀並清理簿記;如果沒有配置，VFS 鎖定本身就無法復原，而且會在檔案或連線中斷時釋放。修正案例 1 和 2，方法是將 locks_free_lock（）/kfree（） 提升到 UNLOCK 分支中的 if（！rc） 檢查之前，以便所有退出路徑共用一個空閒網站，並在非 UNLOCK 分支中釋放 smb_lock 和 flock。在這兩種情況下傳播正確的錯誤代碼。透過將 VFS 解鎖包裝在 if（rlock） 保護中，並在共用清理中新增 locks_free_lock（rlock） 的 NULL 檢查，以修正案例 3。透過使用 sqry 的呼叫圖分析找到。（CVE-2026-31477）

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

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

  - udp：修正使用hash2時的萬用字元綁定衝突檢查。當將udp_sock綁定到本地位址與埠時，UDP使用兩個雜湊值（udptable->hash與udptable->hash2）來進行碰撞偵測。當前程式碼在 hslot-> count > 10 時切換為 hash2。Hash2 以本地位址和本地埠口來鍵控。雜湊值僅由本地埠鍵控。問題可透過以下綁定序列（偽代碼）表示：bind（fd1， [fd00：：1]：8888） bind（fd2， [fd00：：2]：8888） bind（fd3， [fd00：：3]：8888） bind（fd4， [fd00：：4]：8888） bind（fd5， [fd00：：5]：8888） bind（fd6， [fd00：：6]：8888） bind（fd7， [fd00：：7]：8888） bind（fd8， [fd00：：8]：8888） bind（fd9， [fd00：：9]：8888） bind（fd10， [fd00：：10]：8888） /* 正確返回
    -EADDRINUSE，因為用的是雜湊值 * 而非 hash2。udp_lib_lport_inuse（） 偵測 * 衝突。*/ bind（fail_fd， [：：]：8888） /* 當再綁定一個 socket 到 [fd00：：11]：8888 後，* hslot-> count 超過 10，改用 hash2。*/ bind（fd11， [fd00：：11]：8888） bind（fail_fd， [：：]：8888） /* 意外成功 */ 同樣的問題也發生在 IPv4 萬用卡位址 0.0.0.0 和 IPv4 映射的萬用卡位址 ：：ffff：0.0.0.0。例如，若存在綁定到 192.168.1.[ 的套接字1-11]：8888，然後 0.0.0.0結合 ：8888 或 [：：FFFF：0.0.0.0]：8888 也可能會在 hslot->count > 10 時錯過衝突。
    TCP inet_csk_get_port（） 已經在 inet_use_bhash2_on_bind（） 中有正確的檢查。把它重新命名為 inet_use_hash2_on_bind（），並移到 inet_hashtables.h，這樣 udp.c 才能在這個修正中重複使用它。
    (CVE-2026-31503)

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

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

  - 藍牙L2CAP修正 l2cap_conn_del() l2cap_conn_del() 呼叫 cancel_delayed_work_sync() 的 info_timer 和 id_addr_timer 在保持 conn->lock 時鎖死。不過如果 l2cap_conn_del() 取得鎖定時若已執行工作函式 l2cap_info_timeout() 與 l2cap_conn_update_id_addr() 會同時取得 conn->lock進而建立潛在的 AB-BA 鎖死問題。在取得 conn->lock 前移動工作取消並使用 disable_delayed_work_sync()額外防止工作在取消後重新部署這與 hci_conn_del() 中使用的模式一致。
    (CVE-2026-31499)

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

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

  - af_key驗證 pfkey_send_migrate() 中的系列 syzbot 可在 skb_put() 中觸發當機 [1] 問題是 pfkey_send_migrate() 未檢查舊/新系列且 set_ipsecrequest() @family 引數遭截斷因此可能過度填滿 skb。提早驗證系列不等待 set_ipsecrequest()。 [1] skbuffskb_over_panictext:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev:<NULL> net/core/skbuff.c:214! 的核心錯誤呼叫追踪：
    <TASK> skb_over_panic net/core/skbuff.c:219 [內嵌] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [內嵌] set_ipsecrequest net/key/af_key.c :3532 [內嵌] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0xfrm_do_migrate+0888 /0xaa0 net/xfrm/xfrm_user.c:3150 (CVE-2026-31515)

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

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

  - bpf：修正直譯器 sdiv/smod 中未定義的行為INT_MIN BPF 直譯器的有號 32 位元除法與模組處理程序在 s32 運算元上使用 kernel abs（） 巨集。abs（） 巨集文件（include/linux/math.h）明確表示，當輸入為型別最小值時，結果為未定義。當 DST 包含 S32_MIN （0x80000000） 時，abs（（s32）DST） 會觸發未定義行為，並在 arm64/x86 上回傳S32_MIN不變。此值隨後以符號擴展至 u64 作為 0xFFFFFFFF80000000，導致 do_div（） 計算錯誤結果。驗證器的抽象詮釋（scalar32_min_max_sdiv）計算出數學上正確的範圍追蹤結果，造成驗證器與解譯器的不匹配，進而被利用以取得超出範圍的地圖值。引入 abs_s32（），透過在負值前先投擲到 u32，正確處理S32_MIN，完全避免有符號溢出。在直譯器的 sdiv32/smod32 處理器中替換所有 8 個 abs（（s32）...） 呼叫站點。S32 是唯一受影響的案例——S64 部門/Modulo 處理員不使用 ABS（）。（CVE-2026-31525）

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

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

  - uutils coreutils 的 env 工具邏輯錯誤，導致使用 -S（分割字串）選項時無法正確解析命令列參數。在 GNU 環境中，單引號內的反斜線會被字面處理（\\ 和 \' 除外）。然而，uutils 實作錯誤地嘗試驗證這些序列，導致序列錯誤，當遇到有效但未被識別的序列 \a 如 或 \x時，程序立即終止，退出狀態為 125。
    這種與 GNU 行為的差異破壞了依賴標準分割字串語意的自動化腳本與管理工作流程的相容性，導致這些操作在本地被拒絕服務。
    (CVE-2026-35377)

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

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

  - net/smc修正 tee() 複製接合管道緩衝區時出現的 smc_spd_priv 重複釋放 smc_rx_splice() 會為每個 pipe_buffer 配置一個 smc_spd_priv並將指標儲存在 pipe_buffer.private 中。這些緩衝區的 pipe_buf_operations 使用 .get = generic_pipe_buf_get這只會在 tee(2) 複製管道緩衝區時增加頁面參照計數。系統並未處理 smc_spd_priv 指標本身因此在 tee() 之後原始與復制的 pipe_buffer 共用相同的 smc_spd_priv *。隨後釋放兩個管道時系統會針對相同的物件呼叫 smc_rx_pipe_buf_release() 兩次第一次呼叫
    kfree(priv) sock_put(sk) smc_rx_update_cons() [更正] 第二個呼叫 kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF] KASAN 報告 smc_rx_pipe_buf_release() 中有 slab 釋放後使用問題然後升級至追踪已釋放的 priv->smc 指標時透過 smc_rx_update_consumer() 會發生一個 NULL 指標解除參照和核心錯誤錯誤KASAN在 smc_splice_tee_ 工作在 addr ffff888004a45740 讀取 smc_rx_pipe_buf_release+0x78/0x2a0 中大小為 8 的釋放後使用/74 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6 /0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: <TASK> smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+ 0x1c6/0x490
    __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 核心錯誤 - 未同步嚴重例外狀況之外除了記憶體安全問題複製 SMC 接合緩衝區在語意上也有問題smc_rx_update_cons() 會使取用者游標前進兩次損毀接收視窗計量。smc_spd_priv 的 refcount 可修正重複釋放但 cursor-accounting 問題仍需個別解決。tee(2) 和 splice_pipe_to_pipe() 都會針對部分傳輸叫用 .get 回呼兩者現在都會傳回 -EFAULT。需要復制 SMC 通訊端資料的使用者必須使用複制型讀取路徑。 (CVE-2026-31507)

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

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

  - 當實際 UID 和有效 UID 不同時，uutils coreutils 中的 id 公用程式在其漂亮的列印輸出中表現出不正確的行為。實作在為有效使用者執行名稱查詢時，錯誤地使用有效 GID 而非有效 UID。這會導致誤導性診斷輸出，導致自動化指令碼或系統管理員在檔案權限或存取控制方面做出錯誤的決策。（CVE-2026-35371）

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

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

  - 團隊：修正非乙太網路埠的類型混淆header_ops類似於提交 950803f72547（綁定：修正 bond_setup_by_slave（））中的類型混淆），團隊擁有相同類別的 header_ops 類型混淆。對於非乙太網路埠，team_setup_by_port（） 直接複製 port_dev->header_ops。當團隊裝置後來呼叫 dev_hard_header（） 或 dev_parse_header（） 時，這些回調可能會與團隊net_device一同執行，而非真實的較低層裝置，因此 netdev_priv（開發）會被解讀為錯誤的私有類型，可能導致當機。syzbot 報告顯示 bond_header_create（） 中發生崩潰，但根本原因在團隊中：拓撲為 gre -> bond -> 團隊，團隊呼叫繼承的header_ops時使用自己的net_device而非較低的裝置，因此 bond_header_create（） 接收團隊裝置並將 netdev_priv（） 解讀為綁定私人資料， 造成型別混淆崩潰。解決方法是引入 Team header_ops 包裝器來建立/解析，選擇 RCU 下的 team 埠，並用 port->dev 呼叫較低的裝置回調，讓每次回調都能看到正確的 net_device 上下文。同時也將選中的較低裝置傳遞給較低的解析回撥，使遞迴在堆疊的非乙太網路拓撲中受限，且解析回撥總是在正確的裝置上下文下執行。（CVE-2026-31502）

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

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

  - nvme-pci：確定我們正在輪詢已輪詢的佇列 使用者可以在執行階段變更輪詢的佇列計數。
    在重設期間有一個短暫的窗口，hipri 任務可能會嘗試在區塊層更新佇列映射之前輪詢該佇列，這將與現在中斷驅動的佇列競爭，並可能導致重複完成。（CVE-2026-31523）

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

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

  - 模組修正符號 st_shndx 超出邊界時發生的核心錯誤 模組載入器不會檢查 simple_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym) 中 ELF 區段索引的邊界;
    i++) { const char *name = info->strtab + sym[i].st_name; switch (sym[i].st_shndx) { case SHN_COMMON: [...] default/* 如果是 percpu var. 則轉移至 percpu 配置。 */ if (sym[i].st_shndx == info->index.pcpu) secbase = (unsigned long)mod_percpu(mod); else /** HERE --> **/ secbase = info->sechdrs[sym[i].st_shndx].sh_addr; sym[i].st_value += secbase中斷具有超出邊界 st_shndx 值 (例如 0xffff) (稱為 SHN_XINDEX 或 SHN_HIRESERVE) 的符號可能會造成核心錯誤錯誤無法處理位址 ... 的頁面錯誤RIP: 0010:simplify_symbols+0x2b2/0x480 ... 核心錯誤 - 未同步嚴重例外狀況此錯誤可能會發生在模組 ELF 合法使用 SHN_XINDEX 或模組損毀時。在 simple_symbols() 中新增邊界檢查以便在使用 st_shndx 之前先對其進行驗證。此問題的發現是因為 llvm-objcopy 中的一個錯誤所導致請參閱相關討論了解詳情 [1]。 [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/ (CVE-2026-31521)

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

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

  - ksmbd修正複合要求的 QUERY_INFO 中的 OOB 寫入。當收到如 READ + QUERY_INFO(Security) 的複合要求且第一個命令 (READ) 消耗大部分的回應緩衝區時ksmbd 在建置安全性描述元。根本原因是 smb2_get_info_sec() 使用 xattr 的 ppntsd_size 檢查緩衝區空間而 build_sec_desc() 經常從 POSIX ACL 合成大很多的描述符號。此修補程式引入 smb_acl_sec_desc_scratch_len()可預先準確計算最終描述符號大小使用 smb2_calc_max_out_buf_len() 執行適當緩衝區檢查並使用確切大小配置 + iov 釘選。
    (CVE-2026-31432)

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

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

  - NET：MACB：使用目前的隊列號碼來顯示統計資料。保留給統計資料的記憶體與寫入的記憶體量之間可能存在不匹配。gem_get_sset_count（） 會根據活動佇列正確計算統計數量，而 gem_get_ethtool_stats（） 則會以最大隊列數量無差別複製資料，若活動佇列數少於 MACB_MAX_QUEUES，則會如 KASAN splat 所示出現 OOB 寫入。
    ================================================================== 錯誤：KASAN：vmalloc-out-of-bounds in in the gem_get_ethtool_stats+0x54/0x78 [macb] 任務ethtool/1027 在 addr ffff80008080b000 寫入大小 760 CPU： [...]受污染：[E]=UNSIGNED_MODULE 硬體名稱：raspberrypi rpi/rpi，BIOS 2025.10 2025/01/10 呼叫追蹤：show_stack+0x20/0x38 （C） dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 錯誤位址屬於從0xffff80008080b000起的 1 頁 vmalloc 區域，分配至 dev_ethtool+0x11f0/0x38c0 錯誤位址屬於實體頁面：page： refcount：1 mapcount：0 mapping：0000000000000000000000 index：0xffff00000a333000 pfn：0xa333 flags： 0x7fffc000000000（node=0|zone=0|lastcpupid=0x1ffff） raw： 007fffc000000000 0000000000000000 dead0000000000122 00000000000000000000 raw： ffff00000a330000 00000000000000001ffffffff 00000000000000000000 頁面被傾倒 原因：kasan：偵測到錯誤存取 錯誤位址周圍的記憶體狀態：
    FFFF80008080b080： 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FFFF80008080b100： 00 00 00 00 00 00 00 00 00 00 00 00 >FFFF80008 080b180： 00 00 00 00 00 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 ^ FFFF80008080B200： F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 FFFF80008080B280： f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== 解決方法是確保複製的大小只考慮活躍佇列數量。（CVE-2026-31494）

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

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

  - 已解決 Linux 核心中的下列弱點：RDMA/irdma: Harden depth calculation functions An issue was exposed where OS can pass in U32_MAX for SQ/RQ/SRQ size. This can cause integer overflow and truncation of SQ/RQ/SRQ depth returning a success when it should have failed. Harden the functions to do all depth calculations and boundary checking in u64 sizes. (CVE-2026-31491)

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

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

  - 追踪以 osnoise 修正 cpu 熱插拔中的潛在鎖死。下列序列可能導致 cpu 熱插拔鎖死task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock( ); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion() osnoise_sleep();
    mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK] 透過交換 cpus_read_lock() 和 mutex_lock(&interface_lock) 的順序修正。 (CVE-2026-31480)

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

ID	名稱	嚴重性
309839	Linux Distros 未修補的弱點：CVE-2026-35359	medium
309838	Linux Distros 未修補的弱點：CVE-2026-31497	medium
309837	Linux Distros 未修補的弱點：CVE-2026-35355	medium
309836	Linux Distros 未修補的弱點：CVE-2026-35351	medium
309835	Linux Distros 未修補的弱點：CVE-2026-35340	medium
309834	Linux Distros 未修補的弱點：CVE-2026-35373	medium
309833	Linux Distros 未修補的弱點：CVE-2026-31528	high
309832	Linux Distros 未修補的弱點：CVE-2026-31504	high
309831	Linux Distros 未修補的弱點：CVE-2026-31519	medium
309830	Linux Distros 未修補的弱點：CVE-2026-31476	high
309829	Linux Distros 未修補的弱點：CVE-2026-35365	medium
309828	Linux Distros 未修補的弱點：CVE-2026-31513	high
309827	Linux Distros 未修補的弱點：CVE-2026-35370	medium
309826	Linux Distros 未修補的弱點：CVE-2026-31496	medium
309825	Linux Distros 未修補的弱點：CVE-2026-31508	high
309824	Linux Distros 未修補的弱點：CVE-2026-31516	high
309823	Linux Distros 未修補的弱點：CVE-2026-35366	medium
309822	Linux Distros 未修補的弱點：CVE-2026-31527	high
309821	Linux Distros 未修補的弱點：CVE-2026-35379	low
309820	Linux Distros 未修補的弱點：CVE-2026-35361	medium
309819	Linux Distros 未修補的弱點：CVE-2026-31505	high
309818	Linux Distros 未修補的弱點：CVE-2026-31493	high
309817	Linux Distros 未修補的弱點：CVE-2026-35339	medium
309816	Linux Distros 未修補的弱點：CVE-2026-35360	medium
309815	Linux Distros 未修補的弱點：CVE-2026-35380	medium
309814	Linux Distros 未修補的弱點：CVE-2026-31483	medium
309813	Linux Distros 未修補的弱點：CVE-2026-35381	low
309812	Linux Distros 未修補的弱點：CVE-2026-35354	medium
309811	Linux Distros 未修補的弱點：CVE-2026-35367	low
309810	Linux Distros 未修補的弱點：CVE-2026-31486	high
309809	Linux Distros 未修補的弱點：CVE-2026-35341	high
309808	Linux Distros 未修補的弱點：CVE-2026-31488	high
309807	Linux Distros 未修補的弱點：CVE-2026-31461	medium
309806	Linux Distros 未修補的弱點：CVE-2026-35342	low
309805	Linux Distros 未修補的弱點：CVE-2026-31479	high
309804	Linux Distros 未修補的弱點：CVE-2026-31477	high
309803	Linux Distros 未修補的弱點：CVE-2026-31503	medium
309802	Linux Distros 未修補的弱點：CVE-2026-31499	medium
309801	Linux Distros 未修補的弱點：CVE-2026-31515	medium
309800	Linux Distros 未修補的弱點：CVE-2026-31525	high
309799	Linux Distros 未修補的弱點：CVE-2026-35377	low
309798	Linux Distros 未修補的弱點：CVE-2026-31507	high
309797	Linux Distros 未修補的弱點：CVE-2026-35371	low
309796	Linux Distros 未修補的弱點：CVE-2026-31502	high
309795	Linux Distros 未修補的弱點：CVE-2026-31523	medium
309794	Linux Distros 未修補的弱點：CVE-2026-31521	medium
309793	Linux Distros 未修補的弱點：CVE-2026-31432	high
309792	Linux Distros 未修補的弱點：CVE-2026-31494	high
309791	Linux Distros 未修補的弱點：CVE-2026-31491	medium
309790	Linux Distros 未修補的弱點：CVE-2026-31480	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

medium

high

high

medium

high

medium

high

medium

medium

high

high

medium

high

low

medium

high

high

medium

medium

medium

medium

low

medium

low

high

high

high

medium

low

high

high

medium

medium

medium

high

low

high

low

high

medium

medium

high

high

medium

medium