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 依賴供應商報告的套件存在。

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

  - HIDmagicmouse避免 magicmouse_report_fixup() 中發生記憶體洩漏 magicmouse_report_fixup() 函式會傳回 kmemdup() 新配置的緩衝區但從未將其釋放。report_fixup() 的呼叫者並未取得傳回指標的擁有權但 **允許其傳回輸入 rdesc 的存留期由呼叫者管理的子部分。 (CVE-2026-31522)

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

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

  - canisotp修正 isotp_sendmsg() 中的 tx.buf 釋放後使用錯誤 isotp_sendmsg() 僅使用 so->tx.state 上的 cmpxchg()來序列化對 so->tx.buf 的存取。 isotp_release() 透過 wait_event_interruptible() 等待 ISOTP_IDLE然後呼叫 kfree(so->tx.buf)。tx.state 為 ISOTP_SENDING 時若有訊號中斷 close() 內的 wait_event_interruptible()則迴圈會提早結束且釋出會繼續強制執行 ISOTP_SHUTDOWN並繼續執行 kfree(so->tx.buf)而 sendmsg 可能仍會讀取 so-> isotp_fill_dataframe() 中最終 CAN 框架的 tx.buf。當標準 tx.buf 長度需要延伸時可配置一次 so->tx.buf。當 isotp_sendmsg() 或 isotp_release() 執行完畢時將此可能延伸的 tx.buf 的 kfree() 移至 sk_destruct 時間。 (CVE-2026-31474)

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

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

  - uutils coreutils 的 rm 工具存在漏洞，允許繞過保護。--preserve-root
    實作使用路徑字串檢查，而非比較裝置與 inode 編號來識別根目錄。攻擊者或意外使用者可透過符號連結（如 /tmp/rootlink -> /）來繞過此防護，可能導致整個根檔案系統意外遞迴刪除。（CVE-2026-35349）

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

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

  - 在 uutils coreutils 的 mv 工具中，存在一個檢查時間到使用時間（TOCTOU）競賽條件，適用於跨裝置操作期間。該工具會先移除目的路徑，再透過複製操作重新建立。擁有寫入目的目錄的本地攻擊者可利用此視窗，將目的地換成符號連結。隨後的特權移動操作會跟隨符號連結，讓攻擊者能將寫入並覆蓋任意目標檔案，並用原始碼的內容。（CVE-2026-35364）

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

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

  - uutils coreutils 的 expr 工具邏輯錯誤會導致程式在解析階段而非執行階段評估括號內子表達式。此實作缺陷使該工具無法對邏輯 OR （|） 與 AND（&） 操作進行適當的短路。因此，死枝內出現的算術錯誤（如除以零）會被當作致命錯誤提出，這些分支因短路而應被忽略。這種與 GNU expr 行為的偏離可能導致 shell 腳本中的受保護表達式出現硬錯誤，而非回傳預期的布林結果，導致腳本過早終止並中斷 GNU 相容的 shell 控制流程。（CVE-2026-35378）

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

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

  - 藍牙MGMT修正 mgmt_add_adv_patterns_monitor_complete 上的懸置指標這可修正條件檢查因此只要 status != -ECANCELED 呼叫 mgmt_pending_free(cmd)會在未先將其與清單取消連結的情況下對其進行 kfree(cmd) mgmt_pending_valid從而留下懸置指標。任何後續的清單遊走 (例如__mgmt_power_off 期間的 mgmt_pending_foreach 或其他 mgmt_pending_valid 呼叫) 都會解除參照釋放的記憶體。 (CVE-2026-31511)

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

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

  - drm/amdgpu：防止立即 PASID 重用，PASID 重新使用可能導致中斷問題，當程序立即進入前一個以相同 PASID 退出的程序所留下的硬體狀態時，程序退出並釋放 PASID 時，IH 環緩衝區中可能仍有頁面錯誤待處理。為了避免這種情況，它使用 idr 循環配置器，與 kernel PID 相同。（摘自提交 8F1DE51F49BE692DE137C8525106E0FCE2D1912D）（CVE-2026-31462）

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

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

  - uutils coreutils 中的 cp 工具易受到資訊揭露競賽條件的影響。目的檔案最初以 umask 衍生的權限（例如 0644）建立，之後才會被限制為最終模式（例如 0600）。本地攻擊者可以在這個視窗內競速打開檔案;一旦取得，即使權限被收緊，檔案描述符仍有效且可讀，暴露敏感或私密檔案內容。（CVE-2026-35357）

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

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

  - uutils coreutils 中的 cp 工具在執行遞迴複製（-R）時，錯誤地將字元與區塊裝置節點視為串流來源，而非保留它們。由於實作是在目的地將位元組讀取到一般檔案，而非使用 mknod，裝置語意會被破壞（例如 /dev/null 變成一般檔案）。此行為可能導致執行時因磁碟耗盡而拒絕服務，或在讀取無界裝置節點時程序掛機。（CVE-2026-35358）

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

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

  - 使用 --userspec 選項時uutils coreutils 的 chroot 公用程式中存在一個弱點。公用程式會在進入 chroot 之後卸除 root 權限之前透過 getpwnam() 解析使用者規格。在 glibc 型系統上這可觸發 Name Service Switch (NSS) 從新的 root 目錄載入共用程式庫 (例如 libnss_*.so.2)。如果 NEWROOT 可由攻擊者寫入便可插入惡意 NSS 模組以 root 身分執行任意程式碼進而促成完整的容器逸出或權限提升。 (CVE-2026-35368)

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

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

  - uutils coreutils 中的排序工具在輸入包含非 UTF-8 檔名時，容易發生程序緊急。--files0-from 實作強制執行 UTF-8 編碼，並使用 expect（），當遇到有效但非 UTF-8 路徑時會立即當機。這與 GNU 排序不同，後者將檔名視為原始位元組。本地攻擊者可以利用此漏洞癱瘓該工具並中斷自動化管線。（CVE-2026-35348）

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

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

  - uutils coreutils 中的切割工具在指定換行字元作為分隔符時，錯誤處理了 -s（僅分隔）選項。實作未能在 cut_fields_newline_char_delim 函式中驗證 only_delimited 標誌，導致工具列印本應被抑制的非分隔線。這可能導致意外資料傳入依賴嚴格輸出過濾的下游腳本。（CVE-2026-35343）

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

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

  - 藍牙L2CAP：針對 BT_CONNECTED 狀態的通道修正 ERTM re-init 和零 pdu_len 無限迴圈 l2cap_config_req() 處理程序 CONFIG_REQ 以支援 L2CAP 重新組態 (例如 MTU 變更)。不過由於 CONF_INPUT_DONE 和 CONF_OUTPUT_DONE 已從初始組態設定因此重新組態路徑會結束至 l2cap_ertm_init()其會重新初始化 tx_q、srej_q、srej_list 和 retrans_list而不釋放先前的配置並將 chan->sdu 設為 NULL且不釋放現有的 skb。這會洩漏所有先前配置的 ERTM 資源。此外l2cap_parse_conf_req() 不會驗證衍生自 RFC max_pdu_size 選項的 remote_mps 最小值。一個零值會傳播到 l2cap_segment_sdu()其中 pdu_len 變成零導致 while 迴圈由於 len 從未遞減而永遠不會終止進而耗盡所有可用記憶體。修正在通道已處於 BT_CONNECTED 狀態時略過 l2cap_ertm_init() 和 l2cap_chan_ready() 的 double-init同時仍允許透過 l2cap_parse_conf_req() 更新重新組態參數。也可在 l2cap_segment_sdu() 中新增 pdu_len 零檢查作為保護措施。 (CVE-2026-31498)

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

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

  - uutils coreutils 的 ln 工具邏輯錯誤，即使明確提供（或 -n）標誌，工具仍可取消參考符號連結目標 --no-dereference 。先前的實作僅在啟用（覆寫）模式時 --force ，才會尊重無去參照意圖。此缺陷導致 LN 跟隨指向某個目錄的符號連結，並在該目標目錄內建立新連結，而非將符號連結本身視為目的地。在有特權使用者或系統腳本使用 ln -n 更新符號連結的環境中，本地攻擊者可能會操控現有的符號連結，將檔案建立導向敏感目錄，可能導致未經授權的檔案建立或系統設定錯誤。（CVE-2026-35372）

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

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

  - s390/entry：清理核心項目上的 r12 暫存器 在提交 f33f2d4c7c80 （s390/bp：移除 TIF_ISOLATE_BP） 之前，所有項目處理常式都會將目前任務指標 （lg %r12，__LC_CURRENT） 載入 r12，以供 BPENTER/BPEXIT 巨集使用。該提交刪除了TIF_ISOLATE_BP，刪除了分支預測巨集和 r12 載入，但沒有將 r12 添加到暫存器清除序列中。新增缺少的 xgr %r12，%r12，以使暫存器清理在所有進入點上保持一致。（CVE-2026-31482）

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

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

  - 藍牙：L2CAP：在讀取 l2cap_ecred_data_rcv（） 中的 SDU 長度之前，先驗證 PDU 長度 l2cap_ecred_data_rcv（） 會使用 get_unaligned_le16（） 從 skb->data 讀取 SDU 長度欄位，而無需先驗證 skb 是否包含至少 L2CAP_SDULEN_SIZE （2） 個位元組。當 skb->len 小於 2 時，這會讀取 skb 中的有效資料。ERTM 重組路徑會在讀取 SDU 長度之前正確呼叫 pskb_may_pull（） （l2cap_reassemble_sdu，情況L2CAP_SAR_START）。將相同的驗證套用至增強型信用型流量控制資料路徑。（CVE-2026-31512）

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

ID	名稱	嚴重性
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
309789	Linux Distros 未修補的弱點：CVE-2026-31522	medium
309788	Linux Distros 未修補的弱點：CVE-2026-31474	high
309787	Linux Distros 未修補的弱點：CVE-2026-35349	high
309786	Linux Distros 未修補的弱點：CVE-2026-35364	medium
309785	Linux Distros 未修補的弱點：CVE-2026-35378	low
309784	Linux Distros 未修補的弱點：CVE-2026-31511	high
309783	Linux Distros 未修補的弱點：CVE-2026-31462	medium
309782	Linux Distros 未修補的弱點：CVE-2026-35357	medium
309781	Linux Distros 未修補的弱點：CVE-2026-35358	medium
309780	Linux Distros 未修補的弱點：CVE-2026-35368	high
309779	Linux Distros 未修補的弱點：CVE-2026-35348	medium
309778	Linux Distros 未修補的弱點：CVE-2026-35343	low
309777	Linux Distros 未修補的弱點：CVE-2026-31498	medium
309776	Linux Distros 未修補的弱點：CVE-2026-35372	medium
309775	Linux Distros 未修補的弱點：CVE-2026-31482	medium
309774	Linux Distros 未修補的弱點：CVE-2026-31512	medium

偵測

Nessus 的 Misc. 系列

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

medium

high

high

medium

low

high

medium

medium

medium

high

medium

low

medium

medium

medium

medium