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

  - USB：小工具：uvc：修正 uvc_function_bind（） 和 uvc_function_unbind（） 中的懸空指標 在 uvc_function_bind（） 錯誤路徑中，我們使用 usb_ep_free_request，它使用 uvc->control_req，但之後不會將其設定為 NULL。因此，uvc->control_req 是一個懸空指標，導致 UAF。此外，我們不會在釋放 uvc->control_buf 指標後將其設定為 NULL，這是另一個懸空指標。透過在執行 usb_ep_free_request（） 後將 uvc->control_req 設定為 NULL，在 kfree 之後將 uvc->control_buf 設定為 NULL 來修正它。對 uvc_function_unbind（） 執行相同的操作。（CVE-2026-89733）

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

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

  - SUNRPC： xdr_buf_trim：clamp buf->len 以避免下溢 xdr_buf_trim（） 透過遍歷尾部、頁面和頭部 iovec 從xdr_buf尾部修剪 'len' 位元組。每個每節步驟都使用 min_t（），因此它永遠不會刪除超過該節所包含的位元組，但fix_len標籤的最終會計會從 buf->len 中減去實際消耗的總位元組，而無需任何限制：fix_len：buf->len -= （len - trim）;當調用方將 buf->len 設定為小於iov_lens總和的值時，（len - trim） 可以超過 buf->len，並且無符號減法換行到接近 UINT_MAX。gss_krb5_unwrap_v2（） 在該狀態下到達 xdr_buf_trim（）：buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip;buf->len = len - （GSS_KRB5_TOK_HDR_LEN + headskip）;xdr_buf_trim（buf， ec + GSS_KRB5_TOK_HDR_LEN + 尾跳）;buf->len 是一個小的有線派生值，而 iov_lens 是頁面規模，因此每個部分的循環合法地消耗的位元組比 buf->len 記錄多得多。然後，包裝的 buf->len 會作為權威資料流傳播到每個下游 XDR 解碼器中。透過限制遞減來修復，使 buf->len 在零處觸底：buf->len -= min_t（unsigned int， buf->len， len - trim）;在 buf->len 的iov_lens總和的正常路徑上，（len - trim） 始終為 <= buf->len，結果與之前相同。不會有呼叫者變更反向溢位案例之外的行為。（CVE-2026-89551）

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

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

  - 已解決 Linux 核心中的下列弱點：net: bnxt: ring the doorbell when SW USO exits early When a burst of packets is handed down to the driver, the driver defers the doorbell to the end by setting txr->kick_pending = 1. The normal TX path handles this, but the SW USO path can miss it if it returns early. If bnxt_sw_udp_gso_xmit runs but returns early with NETDEV_TX_BUSY and txr->kick_pending was previously set to 1, then the TX queue can stall because the driver wrote some BDs but never wrote the doorbell. The device won't know to do the TX which would generate the completion that would wake the queue back up. Simplify bnxt_sw_udp_gso_xmit to set txr->kick_pending in its success case and check the flag on return. The added check after bnxt_sw_udp_gso_xmit returns ensures that any pending doorbells are written handling both successful USO and any early returns, which prevents the TX queue stall mentioned above. This TX queue stall was observed on a production system with a netdev TX watchdog informing about the queue stall. (CVE-2026-80998)

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

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

  - ceph：在解鎖期間釋放的 cf 項目上修正 __kick_flushing_caps（） 中的 UAF list_for_each_entry（） 會反覆運算 ci->i_cap_flush_list，但會丟棄傳送上限訊息的 i_ceph_lock。在解鎖窗口期間，handle_cap_flush_ack（） 可以獲取i_ceph_lock，從列表中分離具有 tid <= flush_tid 的 cf 項目，釋放i_ceph_lock，並通過任何鎖之外的 ceph_free_cap_flush（） 釋放它們。當原始執行緒重新取得i_ceph_lock並且 for 迴圈巨集透過 cf = list_next_entry（cf， i_list） 前進時，它會在釋放的記憶體上取消參照 cf->i_list.next。爭用時間軸： __kick_flushing_caps（） handle_cap_flush_ack（） ----------------------- -----------------------保留i_ceph_lock <---迭代到 cf （tid=10） 準備 FLUSH 訊息丟棄 i_ceph_lock <--- __send_cap（） FLUSH（tid=10） MDS 傳送 FLUSH_ACK（tid=10） --->取得 i_ceph_lock cf->tid（10） <= flush_tid（10），將 cf 從 i_cap_flush_list 刪除 i_ceph_lock ceph_free_cap_flush（cf） <- 釋放它！取得 i_ceph_lock <--- for 迴圈前進： cf = list_next_entry（cf， i_list） -- 釋放的 cf->i_list.next 上的 UAF 剛剛由
    透過 __send_cap（） 自行__kick_flushing_caps。MDS 可能會以足夠快的速度回應 FLUSH_ACK，以至於 handle_cap_flush_ack（） 在__kick_flushing_caps完成反覆運算之前釋放 cf。透過轉換為手動 while 迴圈來修復：在刪除之前將下一個指標保存在 i_ceph_lock 下，然後在重新獲取後使用已儲存的指標，這樣就永遠不會再存取潛在釋放的 cf。（CVE-2026-89655）

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

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

  - wifi： rtlwifi： rtl8192du：在索引 TID 之前檢查 QoS TID rtl92du_tx_fill_desc（） 使用 ieee80211_get_tid（） 從標頭讀取 802.11 QoS TID，然後將其用作 sta_entry->tids[] 的索引。 ieee80211_get_tid（） 傳回較低的 4 位 QoS TID 值，因此結果可能在 0..15 範圍內。 rtlwifi 僅為 sta_entry->tids[] 分配MAX_TID_COUNT條目， MAX_TID_COUNT是 9。因此，大於 8 的 QoS TID 會索引超過聚合狀態陣列。保留超出範圍 TID 的預設RTL_AGG_STOP狀態，與 rtl92cu_tx_fill_desc（） 相符。此問題由我們的靜態分析工具偵測到，並透過手動稽核確認。相同錯誤型樣的 UBSAN 驗證會報告 array-index-out-of-bounds 類型「rtl_tid_data [9]」的索引為 10 的存取。（CVE-2026-80943）

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

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

  - sched_ext：修正核心排程下的 rq->core_pick 損毀 核心排程的 pick_next_task（） 會在共用核心範圍的 rq 鎖定下，在單一傳遞中選擇要在核心的每個 SMT 同級上執行的內容。只有在連續持有鎖定時，選擇狀態才一致，因此 ->pick_task（） 原本無法釋放它。但是，由於 4c95380701f5 （sched/ext：將 balance_scx（） 折疊成 pick_task_scx（）），sched_ext從拾取和分派內部執行分派可能會刪除 rq 鎖定。為了支援這一點，pick_next_task（） 已更新，以便在釋放鎖定後，當揀選返回RETRY_TASK時重新啟動整個選擇。當同一核心上的選擇透過丟棄的鎖定交錯時，它們會破壞彼此的狀態：一個清除另一個的 rq->core_pick 導致 NULL 解除參照，或使其保留上一個任務決策失效，使出隊任務繼續執行，這會使下一次喚醒鎖死並匹配報告的硬懸置。SMT 機器上的 cookie 乒乓加載會使交錯頻繁，並在幾秒鐘內殺死核心。透過在分派釋放 rq 鎖定時使選擇返回RETRY_TASK來修正它，以便選擇僅提交在持續保留鎖定下進行的選擇。上一個修補程式的 rq->scx.lock_drop_seq 會計算版本。未觸及任何內容的分派永遠不會釋放鎖定，其判定（包括任何要執行的內容）都有效：重試是有限制的，每次重試都遵循實際執行某些動作的分派，並且閒置的 CPU 不會迴圈。如果另一個分派已經在 rq 上進行中，請跳過分派並從本機已排入佇列的內容中挑選 - 正在進行的分派已釋放鎖定，因此它自己的選擇將重試並重新挑選此 rq，而在此處返回RETRY_TASK只會在分派需要完成的鎖定上旋轉。平衡回呼必須在將其排入佇列的內容中執行，因此它們只能在 CPU 自己的 rq 上排入佇列。針對另一個 rq 分派時，請改為直接執行延遲的工作 - 該 rq 可能會透過核心排程快速路徑耗用其所有選擇，並且永遠不會將回呼本身排入佇列。關於可執行任務被遺忘的 put_prev_task_scx（） 警告假設分派作為正在切換的選擇的一部分運行。現在它只適用於非核心路徑，因此請將其門控並從其條件中刪除 cookie-match 測試，該測試在沒有核心調度的情況下始終為真。
    (CVE-2026-89517)

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

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

  - ZoneMinder 是一款免費的開源閉路電視軟件應用程序。、 1.38.4之前的版本，1.36.39並1.39.11允許具有粗略「Events=View」和/或「Snapshots=View」權限的經過驗證的低權限使用者直接擷取屬於他們不允許存取的監視器事件的媒體。一般 UI 會正確隱藏受限制的監視器及其事件，但直接事件媒體檢視會接受任意「eid」，並從事件路徑串流媒體，而不會強制執行事件/監視器層級 ACL。這暴露了跨監視器邊界的私人監控錄像。版本 1.36.39、 1.38.4和 1.39.11 並修正問題。（CVE-2026-54258）

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

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

  - sched/core：讓核心排程翻轉等候未進行的選取項目 Core 排程的 pick_next_task（） 會在一次取得共用核心範圍鎖定的情況下，在所有同級 rq 上運作。釋放 rq 鎖的 ->pick_task（） 會讓每個同級__lock暫時釋放，讓 __sched_core_flip（false） 完成中間選擇並在其下重新綁定 rq_lockp（）。在分割鎖上恢復選擇，接觸它不再保護的同級狀態，並且 __schedule（） 最終釋放了一個從未被佔用的鎖，同時洩露了曾經被佔用的鎖。在領導者的 rq->core_pick_in_flight 中計算正在進行的核心範圍選擇，並使 __sched_core_flip（） 等待計數耗盡。計數只會在共用鎖定下變更，翻轉會在取樣時保留該鎖定，因此不需要其他排序。當選取項目重疊時，等候可以重複，但樣本之間的翻轉和翻轉是罕見的 cookie 存留期事件。
    sched_core_cpu_deactivate（） 將計數移動到新的領導者 - 如果該 CPU 稍後返回為自己的領導者，則留下的過時副本將永遠偏向它。（CVE-2026-89520）

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

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

  - Ceph：ceph_parse_deleg_inos（） 中的 CAP 委派 inode 計數 ceph_parse_deleg_inos（） 從 MDS 使用委派建立回覆中解碼委派 inode 編號的間隔集。對於每個集合，它會讀取一個 64 位元開始和一個帶有 ceph_decode_64_safe（） 的 64 位元 len，這僅驗證訊息中是否存在八個位元組，而不是值，然後在將條目插入 s_delegated_inos 時循環 len。Len 完全由攻擊者控制。惡意或遭入侵的 MDS 可以傳送一個巨大的間隔、一個回覆中的多個間隔、重複的間隔或重複的回覆，這些回覆會在同一工作階段上累積委派的 inode。
    原始程式碼沒有限制這些，並且可以無限制地旋轉插入迴圈或增長 xarray。
    使用單一強制點綁定兩個維度。在不可部分完成計數器中追蹤每個 MDS 工作階段所持有的委派 inode 數量，並僅在 ceph_insert_deleg_ino（） 中增加它，該 （） 使用 atomic_add_unless（） 拒絕將計數推送超過 CEPH_MAX_DELEG_INOS。因為該協助程式是計數器成長的唯一位置，所以每個會話的母體永遠不會超過上限，因此不需要個別的每個會話預先檢查。當非同步建立耗用委派的 inode 或插入失敗時，計數器會遞減，在還原委派的 inode 時遞增，使用工作階段 xarray 初始化，並在重新連接破壞 xarray 時重設。僅每個會話上限仍然允許一個回覆在重複的範圍內旋轉插入迴圈，而不會增加計數器，因此也限制從單一回覆接受的聚合間隔長度。這些一起綁定了每個回覆的迴圈行程計數和跨回覆的 xarray 母體。上限是固定的、用戶端選擇的常數，而不是從 MDS 衍生的值。
    mds_client_prealloc_inos 是使用者空間 MDS 組態選項;它永遠不會在網路上傳送至核心用戶端，而且在任何情況下都無法信任伺服器提供的界限來進行防禦限制。常數設定得遠高於該選項記錄的預設值 1000 （一個很大的倍數），因此合法的重新填充行為不受影響，而格式錯誤的委派資料流可能消耗的 CPU 和 xarray 記憶體則保持有限。影響：惡意或遭入侵的 Ceph MDS 無法再讓用戶端透過不受限制的委派 inode 間隔旋轉，或無限制地增加一個工作階段的委派 inode xarray。（CVE-2026-89648）

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

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

  - sunrpc：將 rq_argp 和 rq_resp 釋放推遲到 RCU 寬限期 svc_rqst_free（） 之後，透過 kfree（） 同步釋放 rqstp->rq_argp 和 rqstp->rq_resp，但透過 kfree_rcu（） 延遲釋放 rqstp 結構。在 svc_exit_thread（） 呼叫 list_del_rcu（） 和 svc_rqst_free（） 之後，有一個視窗，在 list_del_rcu（） 之前啟動的 RCU 讀取器仍然可以遍歷執行緒清單並找到 rqstp。這些讀者 （例如
    nfsd_nl_rpc_status_get_dumpit（）） 解除參照 rqstp->rq_argp，它已經釋放了釋放後使用。透過將 rq_argp 和 rq_resp 的 kfree 與結構 free 一起移動到明確的 call_rcu（） 回呼中來解決此問題。RCU 讀取器未存取的資源 （bvec、緩衝區頁面、暫存對開本auth_data） 會保持同步釋放。（CVE-2026-89545）

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

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

  - iommufd：在 xa_store（） 失敗時釋放目前的 IOAS，iommufd_take_all_iova_rwsem（） 在將 IOAS 儲存在暫存ioas_list xarray 之前，先採用物件參照和iova_rwsem寫入鎖定。如果 xa_store（） 失敗，則目前的 IOAS 尚未插入ioas_list。
    iommufd_release_all_iova_rwsem（） 只會展開該 xarray 中已經存在的 IOAS 物件，因此無法釋放目前的 IOAS。在回復先前儲存的項目之前，釋放現行 IOAS rwsem 和物件參照。（CVE-2026-89446）

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

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

  - fs：修正巢狀備份檔的使用者路徑 backing_file_open（） 會從 user_file->f_path 派生要儲存在新備份檔中的路徑。當 user_file 本身是備份檔案時，這是不正確的，這是嵌套堆疊檔案系統的情況，例如 overlayfs 掛載，其中一個 overlayfs 的下限目錄是另一個 overlayfs 的合併目錄。由於提交 def3ae83da02 （fs：在後備檔案中儲存真實路徑而不是假路徑 f_path），因此後備檔案的f_path保留中間層的真實路徑，而不是使用者開啟的路徑。提交 924577e4f6ca （ovl：修正巢狀備份檔案路徑） 透過從 ovl_open_realfile（） 傳遞 file_user_path（） 來修正此類配置的此問題。不過，請提交 6af36aeb147a （lsm：
    新增 backing_file LSM 鉤子）將 backing_file_open（） 的第一個引數從使用者路徑改回使用者檔案，並再次從 user_file->f_path 派生路徑，靜默地重新引入問題。因此，透過巢狀 overlayfs 對應的檔案會在 /proc/<pid>/maps 和 perf/ftrace mmap 記錄中顯示錯誤的路徑。例如，使用兩個巢狀 overlayfs 掛載： mkdir -p /ovl/{lower，upper，work，merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower，upperdir=/ovl/upper，workdir=/ovl/work \ /ovl/merged # 當 upperdir 不存在時，至少需要兩個 lowerdir mount -t overlay overlay \ -o lowerdir=/ovl/merged：/ovl/lower /ovl/nested mapping /ovl/nested/foo 顯示中斷連線的路徑，而不是使用者路徑： # readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo 虛假路徑源自中間備份檔的f_path，其掛載是 d_path（） 無法解析的私有複製。使用 file_user_path（） 修正此問題，該路徑會傳回備份檔案的最外層使用者可見路徑，並針對一般檔案回歸 &user_file->f_path。這還原了 overlayfs 的提交 924577e4f6ca （ovl： 修正巢狀備份檔案路徑） 的行為，也修正了其他 backing_file_open（） 呼叫端、fuse passthrough 和 erofs ishare 的相同問題，當其使用者檔案本身是備份檔案時。backing_tmpfile_open（） 具有相同的模式，但不受影響：
    它僅由上層的 ovl_create_tmpfile（） 調用，而另一個 overlayfs 被 ovl_mount_dir_check（） 中的DCACHE_OP_REAL檢查作為上層拒絕，因此其user_file永遠不能是備份檔。（CVE-2026-89768）

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

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

  - SMB： client：以 cifsacl/modefromsid/posix 副檔名寫入時清除 setuid/setgid 位元 當檔案設定了 setuid 或 setgid 位元並被寫入時，VFS 會剝離這些位元，並發出帶有 ATTR_KILL_SUID/ATTR_KILL_SGID 的 setattr 以及帶有已清除模式的ATTR_MODE。在這種情況下，cifs_setattr_unix（） 和 cifs_setattr_nounix（） 都會無條件地丟棄ATTR_MODE： /* 跳過模式更改 （如果只是為了清除 setuid/setgid */ if （attrs->ia_valid &; （ATTR_KILL_SUID|ATTR_KILL_SGID）） attrs->ia_valid &= ~ATTR_MODE;這對於預設掛載來說很好，其中模式僅透過 DOS 唯讀屬性進行模擬，並且無論如何都無法表示 setuid/setgid 位元。但是，使用 cifsacl 或 modefromsid 掛載選項時，模式會透過 ACL （id_mode_to_cifs_acl（）） 儲存在伺服器上，使用 SMB3.1.1 POSIX 延伸模組時，模式會直接傳送至伺服器，而使用 SMB1 Unix 延伸模組 （cifs_setattr_unix） 時，模式會透過 CIFSSMBUnixSetPathInfo（） 傳送。在所有這些情況下，丟棄ATTR_MODE意味著清除的模式永遠不會推送到伺服器，因此 setuid/setgid 位元在寫入過程中仍然存在。這是一個安全性問題：在本機檔案系統上，當寫入檔案時，setuid 位元會被剝離，但透過這些 cifs.ko 掛載，該位元會持續存在於伺服器上，可能會允許在後續執行時意外的權限提升。在兩個地方修正此問題： 1. cifs_setattr_nounix（）：僅當透過 DOS 唯讀屬性模擬模式時（即 cifsacl/modefromsid 和 SMB3.1.1 POSIX 延伸模組均無效），才採用跳過模式變更捷徑，以便在 ACL / POSIX 情況下將清除的模式傳播到伺服器。2、cifs_setattr_unix（）：只有在Unix擴充有效時才調用此函數，因此模式始終儲存在伺服器上。完全移除捷徑，以便一律按下清除模式。（CVE-2026-89638）

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

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

  - ALSA： FCP：不要複製出未初始化的 init 回應 fcp_ioctl_init（） 使用 kmalloc（） 分配其回應緩衝區，並將整個緩衝區複製回使用者空間：buf_size = init.step0_resp_size + init.step2_resp_size;void *resp __free（kfree） = kmalloc（buf_size， GFP_KERNEL）;...if （copy_to_user（arg->resp， resp， buf_size）） return -EFAULT;沒有任何內容會清除緩衝區，其前導 step0_resp_size 位元組的唯一寫入器是 step-0 控制傳輸： err = snd_usb_ctl_msg（dev， usb_rcvctrlpipe（dev， 0）， FCP_USB_REQ_STEP0， USB_RECIP_INTERFACE |USB_TYPE_CLASS |USB_DIR_IN， 0， private->bInterfaceNumber， step0_resp， private->step0_resp_size）;if （err < 0） 傳回 err;
    usb_fill_control_urb（） 不會設定URB_SHORT_NOT_OK，因此短或零長度資料階段會以狀態 0 完成，且 snd_usb_ctl_msg（） 會傳回小actual_length。唯一的檢查是錯誤< 0，因此短傳輸會被視為成功。snd_usb_ctl_msg（） 無條件地複製回完整大小：buf = kmemdup（data， size， GFP_KERNEL）;...memcpy（data， buf， size）;因此，裝置從未寫入的位元組會原封不動地還原為 resp 並複製到使用者空間。step0_resp_size 和 step2_resp_size 分別僅驗證為 1..255，因此呼叫端也會挑選 slab 快取，從 kmalloc-8 到 kmalloc-512。在 7.2.0-rc5 （arm64） 上，裝置以零長度資料階段應答步驟 0，s0 = s2 = 255：# init_on_alloc關閉，無噴霧步驟 0 視窗 [0,255）：nonzero=94/255 000：00 80 60 06 00 00 ff ff 18 00 00 00 57 01 EA 01 010：08 78 22 13 00 00 ff ff ff a8 c4 5f 80 00 80 ff ff # 相同的核心， KMALLOC-512 預先植入 8 位元組標籤 step0 視窗 [0,255）： nonzero=219/255 tagbytes=232 # 相同的執行，init_on_alloc=1 step0 視窗 [0,255）： nonzero=0/255 tagbytes=0 # 所有三次執行 step2 視窗 [255,510）： 裝置字 matched=62/62 a8 c4 5f 80 00 80 ff ff 是 little-endian 核心文字位址 ffff8000805fc4a8。步驟 2 視窗不受影響，因此揭露恰好是步驟 0 區域。將緩衝區歸零，並要求步驟 0 傳輸以傳遞完整的 step0_resp_size 位元組，以便將短資料階段報告為錯誤。
    由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-80970）

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

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

  - ring-buffer：調整 subbuf 大小時按住 cpu_buffer：：lock 因為 ring_buffer_subbuf_order_set（） 可以清除 cpu_buffer->free_page，請按住 cpu_buffer->lock 以防止與 ring_buffer_alloc_read_page（） 和 ring_buffer_free_read_page（） 爭用。（CVE-2026-89501）

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

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

  - 電源：供應：RT9455：拆卸前靜止延遲工作 執行緒 IRQ 處理常式可以將 pwr_rdy_work、max_charging_time_work 和 batt_presence_work排入佇列。pwr_rdy_work和batt_presence_work也可以將max_charging_time_work排入佇列，而batt_presence_work可以自行重新排入佇列。rt9455_remove（） 會在batt_presence_work之前取消max_charging_time_work。因此，後者可以在取消之後將max_charging_time_work排入佇列：rt9455_remove（） 工作佇列取消pwr_rdy_work取消max_charging_time_work batt_presence_work佇列max_charging_time_work取消batt_presence_work傳回 devres 釋放rt9455_info max_charging_time_work取消參照 rt9455_info IRQ 也會保持註冊狀態，直到 devres 清理為止，並且可以在任何取消呼叫之後將更多工作排入佇列。如果在要求 IRQ 之後 rt9455_hw_init（） 失敗，則探查會傳回，而不會取消可能已排入佇列的工作。擱置回呼在釋放後即可存取rt9455_info。在 devm_power_supply_register（） 之後立即註冊 rt9455_cancel_all_delayed_works（） 到 devm_add_action_or_reset（）。devres 會在釋放受管理的 IRQ 之後和釋放 rt9455_info之前，以反向註冊順序呼叫動作，因此延遲的工作會在 rt9455_remove（） 和探查錯誤路徑中清空。取消pwr_rdy_work並在max_charging_time_work之前batt_presence_work，因為兩者都可以將後者排入佇列。此問題是由內部靜態分析工具發現的。（CVE-2026-89465）

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

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

  - mm/migrate_device：釋放 swapcache 後清除過時的對應 __migrate_device_pages（） 會在呼叫 folio_free_swap（） 之前讀取對開本對應。當 folio_free_swap（） 成功時，對開本會從交換快取中移除，但儲存的對應仍指向swap_space。將過時的對應傳遞給 folio_migrate_mapping（） 會使其對不再在交換快取中的對開本使用對應對開本路徑。然後，它可以在具有無效參照統計的 swap_space.i_pages 上運行，最終觸發對開本參照計數 BUG。成功拆分後，nr 仍包含原始大對開本中的頁數，儘管每個產生的頁面現在都是單獨的 order-0 對開本。將 nr 重設為 1，以便個別處理每個分割對開本，包括其自己的交換快取移除和對應查詢。在 folio_free_swap（） 之後重新整理已儲存的對應，以便在移轉期間使用目前的對開本狀態。（CVE-2026-89755）

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

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

  - HID： mcp2221：在 devm 清理回呼 mcp2221_hid_unregister（） 開始時，在hid_hw_stop靜止裝置 IO 之前停止裝置 IO，以便傳入的 HID 報告在探查失敗或裝置移除期間不會與硬體拆卸爭用，從而解決潛在的釋放後使用問題。使用 io_started 保護對 hid_device_io_stop（） 的呼叫。在正常移除中，hid_device_remove（） 在釋放 devres 群組之前就已經清除了 io_started，因此無條件呼叫會命中 ！io_started 路徑，並在每次移除時發出虛假的 io 已停止警告。防護會保留探查失敗平衡，其中 io_started 仍會在 hid_device_io_start（） 之後設定，同時在正常移除路徑上保持靜音。（CVE-2026-89623）

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

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

  - eprosima Fast DDS 是 OMG（物件管理群組）的 DDS（資料分發服務）標準的 C++ 實作。、 3.3.12.14.63.2.4之前3.4.2的版本，2.6.12在處理 RTPS 「DATA_FRAG」子訊息時具有可遠端觸發的越界讀取。攻擊者可以製作具有較大「sampleSize」但實際負載較小的「DATA_FRAG」，並設定「fragmentsInSubmessage」，以便接收者將封包視為最後一個片段**。在此 LAST-fragment 路徑中，Fast-DDS 根據 'sampleSize' 計算 'incoming_length' 並調用 'memcpy（）'，而不驗證 'incoming_data.length >= incoming_length'。因此，'CacheChange_t：：add_fragments（）' 讀取通過接收到的 UDP 數據包緩衝區並讀取到相鄰的堆積內存中，將這些位元組複製到重組緩衝區中。在探索伺服器部署中，產生的「CacheChange_t」可以轉送給其他參與者，這表示新加入的參與者可能會收到洩漏的堆積記憶體 （例如，可能有助於繞過 ASLR 的指標值）。版本 2.6.12、 2.14.6、 3.2.43.3.1，並3.4.2修正問題。（CVE-2026-22590）

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

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

  - apparmor：修正由 begin_current_label_crit_section（） 引起的 cred UAF AppArmor 的 begin_current_label_crit_section（） 是一個可怕的函數，可從許多 LSM 鉤子（特別是與 VFS/通訊端相關的鉤子）調用，它檢查當前 creds 引用的標籤是否標記為FLAG_STALE，如果是，則嘗試使用 aa_replace_current_label（） 將 creds 替換為使用新標籤的更新版本。這樣做的第一個問題是，如果核心中的任何內容採用指向當前憑據的指標並訪問這些，則會直接導致“struct cred”的 UAF，然後通過替換憑據的安全鉤調用，如下所示： ''' const struct cred *cred = current_cred（）;
    alloc_file_pseudo（...）;uid_t uid = cred->euid;''' 我不知道核心中是否有任何東西真的這樣做，但我認為這種模式可能導致 UAF 是非常令人驚訝的。第二個問題是，當 aa_replace_current_label（） 使用覆寫的憑證執行時，會出現問題。
    如果 'current_cred（） ！= current_real_cred（）' （鏡像簽入 proc_pid_attr_write（）），則 aa_replace_current_label（） 會退出，但此檢查實際上無法可靠地偵測覆寫的憑證，因為覆寫的憑證可能與目標憑證相同。因此，在大約以下情況下，事情會出錯： 1. 任務以 （作為客觀和主觀信用） 開 <creds A> 頭，refcount=2 2. 任務獲取一個額外的引用 <creds A> 以覆蓋 3. 任務調用 override_creds（），<creds A>它返回指向舊主觀信用 （） 的指標 4<creds A>. 任務進入 AppArmor LSM 鉤子 5.
    AppArmor 會檢查客觀/主觀信任是否相等 6。AppArmor 將兩個 cred 指標替換為 <creds B> 並在 7 上 <creds A> 刪除 2 個引用。 task 離開 AppArmor LSM hook 8. task 調用 revert_creds（<creds A>） 9. 現在 task->cred 是 <creds A> 而 task->real_cred 是 <creds B>，但task_struct在邏輯上保留兩個對 10 的 <creds B> 引用。 另一個任務刪除了用於覆蓋的額外引用 <creds A> ，refcount 下降到 0 11。 現在 task->real_cred 指向釋放的 creds 此時， 任何對 current_cred（） 的存取都將是 UAF。我有一個測試案例，我在配置文件上運行 aa-disable，而使用該配置文件的進程在 splice（） 上被阻止，從 FUSE 直通文件到一個完整的管道;設定檔更新後，管道變為空，splice（） 恢復，憑證不同步，後續的 getuid（） 系統調用會導致 KASAN UAF splat。若要修正此問題，請不要直接取代 creds，而是透過在目前系統調用結束時執行的task_work來執行。（cred 替換發生的時間點不應對正確性產生影響，這只是為了避免不必要地接觸新標籤的參照計數而進行的性能優化。請注意，在此變更之後，AppArmor 仍會在 sb_pivotroot LSM 勾點中執行直接 cred 替換，並且透過 proc_pid_attr_write（） 在 VFS ->write（） 回呼中仍可直接 cred 替換。如何使用 aa_dup_task_ctx（） 有兩個選項：在複製整個aa_task_ctx後明確重設 new->label_replacement_pending，或切換為手動複製成員。我正在切換到手動複製成員，因為這應該會使錯誤更加明顯。（CVE-2026-89762）

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

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

  - fbdev： ssd1307fb：延遲來自損壞回呼的 I2C 傳輸 當 printk 已停用搶佔時，fbdev 損壞回呼可能會從 fbcon 執行。他們目前同步更新顯示，從原子上下文進入休眠的 I2C 傳輸路徑。系統的完整 RK3566 報告如下： [258.129004] watchdog： watchdog0：watchdog 沒有停止！[ 258.129067] 錯誤：不可部分完成時的排程：
    systemd/1/0x00000003 [ 258.129076] 連結於： algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306（C） fbtft（C） btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil 藍牙 cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2 spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2 stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables x_tables autofs4 [ 258.129215] 在以下位置停用搶佔： [ 258.129216] [<ffff80008012f96c>] vprintk_emit+0x11c/0x340 [ 258.129234] CPU：0 PID：1 通訊：systemd 污染：G C 6.6.0-rc5-rockchip-rk356x #4 [ 258.129239] 硬體名稱：瑞芯微 RK3566 OPi 3B （DT） [ 258.129243] 呼叫追蹤：[ 258.129245] dump_backtrace+0xa0/0x128 [ 258.129252] show_stack+0x20/0x38 [ 258.129256] dump_stack_lvl+0x60/0xb0 [ 258.129265] dump_stack+0x18/0x28 [ 258.129269] __schedule_bug+0xa0/0xc8 [258.129274] __schedule+0x9ac/0xd30 [ 258.129279] schedule+0x60/0x100 [ 258.129282] schedule_timeout+0x194/0x338 [ 258.129289] rk3x_i2c_xfer_common.isra.0+0x384/0x498 [ 258.129296] rk3x_i2c_xfer+0x20/0x60 [ 258.129300] __i2c_transfer+0x194/0x648 [ 258.129308] i2c_transfer+0x9c/0x130 [258.129313 ] i2c_transfer_buffer_flags+0x64/0x98 [ 258.129318] ssd1307fb_update_rect+0x42c/0x560 [ssd1307fb] [ 258.129334] ssd1307fb_defio_imageblit+0x34/0x50 [ssd1307fb] [ 258.129343] soft_cursor+0x13c/0x210 [ 258.129350] bit_cursor+0x2dc/0x550 [ 258.129354] fbcon_cursor+0xec/0x108 [258.129359] hide_cursor+0x44/0xc8 [ 258.129365] vt_console_print+0x398/0x3b0 [ 258.129370] console_flush_all.isra. 0+0x17c/0x410 [ 258.129377] console_unlock+0x4c/0x100 [ 258.129382] vprintk_emit+0x1c8/0x340 [ 258.129386] vprintk_default+0x40/0x58 [ 258.129389] vprintk+0xb8/0xd0 [258.129392 ] _printk+0x68/0x98 [ 258.129398] watchdog_release+0x170/0x230 [ 258.129404] __fput+0xbc/0x288 [258.129409 ] __fput_sync+0x58/0x70 [ 258.129413] __arm64_sys_close+0x40/0x90 [ 258.129419] invoke_syscall+0x4c/0x118 [ 258.129426] el0_svc_common.constprop.0+0x48/0xf0 [ 258.129432] do_el0_svc+0x24/0x38 [ 258.129437] el0_svc+0x48/0x100 [ 258.129443] el0t_64_sync_handler+0xc0/0xc8 [258.129448] el0t_64_sync+0x190/0x198 [ 258.573087] ------------[ 切到這裡 ]------------ [ 258.573098] DEBUG_LOCKS_WARN_ON（val > preempt_count（）） [ 258.573111] 警告： CPU：0 PID：1 在 kernel/sched/core.c：5871 preempt_count_sub+0x9c/0x148 [ 258.573130] 連結於：algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306（C） fbtft（C） btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fansnd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 SSD130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil 藍牙 cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp ---truncated--- （CVE-2026-89598）

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

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

  - SUNRPC：在銷毀 cache_detail sunrpc_destroy_cache_detail（） 之前始終清空cache_cleaner，僅在cache_list為空時取消全域cache_cleaner delayed_work。在 per-netns 拆卸期間，cache_list永遠不會是空的，因為init_net的快取會保持註冊狀態，因此永遠不會觸發取消。取消連結後，呼叫者繼續進行 cache_destroy_net（），這會釋放cache_detail，而 cache_clean（） 可能仍會保留指向它的懸空指標。結果是釋放後使用：cache_dequeue（） 在釋放的記憶體上獲取 cd->queue_lock，而 cache_put（） 將 cd->cache_put 解除參照為釋放 slab 中的函數指標。刪除 list_empty 防護，讓 cancel_delayed_work_sync（） 一律執行，確保任何進行中的 cache_clean（） 在釋放 cache_detail 之前完成。如果其他快取仍註冊，請稍後重新布防清理器。（CVE-2026-89548）

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

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

  - ALSA： pcxhr：在初始化 mgr->lock 之前，先要求執行緒 IRQ pcxhr_probe（） 要求 pcxhr_threaded_irq（） 之前初始化互斥，即使執行緒處理常式採用該互斥。在 request_threaded_irq（） 之前初始化管理程式鎖定，以便在探測期間無法針對未初始化的互斥狀態執行早期中斷。（CVE-2026-80967）

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

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

  - nvme-tcp：拒絕傳輸太少位元組的讀取 nvme_tcp_recv_data（） 會在目前的 C2HData PDU 耗用之後完成要求。沒有任何東西會將收到的總位元組數與命令要求的長度進行比較：struct nvme_tcp_request 沒有接收端計數器，queue->data_remaining 是每個佇列，並且 blk_mq_end_request（） 無條件地完成 blk_rq_bytes（rq），上面沒有殘餘概念。因此，控制器可以使用 512 位元組回應 4096 位元組的讀取，並將其報告為完整讀取;然後用戶空間獲得 4096 個字節，其中 3584 個是頁面中已有的任何字節。我用測試目標再現了這一點。計算在兩個NVME_TCP_F_DATA_SUCCESS路徑和 nvme_tcp_process_nvme_cqe（） 中收到的位元組，並拒絕完成計數不相符的成功讀取。
    成功測試會將 req->status 正確移位，因為驅動程式會保留配線值，並在完成時將其移位，因此檢查必須查看完成路徑將看到的內容。只檢查REQ_OP_READ，因為長度來自請求涵蓋的磁區;直通命令是由其提交者構建的，它同時選擇命令和緩衝區，因此核心沒有什麼可以比較的。
    (CVE-2026-89480)

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

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

  - eprosima Fast DDS 是 OMG（物件管理群組）的 DDS（資料分發服務）標準的 C++ 實作。在 2.6.12版本 、 2.14.6、 3.2.4和 3.4.3之前，Fast DDS 實作的 SQL 型內容篩選 （DDSSQLFilter） 允許 DDS 網域中的任何參與者透過傳送單一特製的 SEDP 'DATA' 子訊息來遠端當機，其 'PID_CONTENT_FILTER_PROPERTY.filterExpression' 包含深度巢狀篩選運算式。版本 2.6.12、 2.14.6、 3.2.4並 3.4.3 修正問題。（CVE-2026-22591）

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

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

  - 藍牙：eir：修正 eir_get_service_data（） 中的 OOB 讀取 eir_get_service_data（） 遍歷具有相符 UUID 的服務資料欄位的廣告資料。在不匹配的情況下，它前進：eir += dlen;eir_len -= 德倫;
    eir_get_data（） 將 dlen 報告為欄位的資料長度，但一旦欄位的長度和類型位元組計入，該欄位就會跨越 dlen + 2 個位元組，當跳過非 Service-Data 欄位以到達該欄位時，該欄位的跨度會更長。指標會正確落在下一個欄位上。eir_len則不會，而且不足值會在欄位之間複合，直到 eir_get_data（） 讀取超出緩衝區結尾的欄位的長度和類型位元組。對於 ISO 廣播接收器，該緩衝區是 hcon->le_per_adv_data[]，從遠端廣播公司的定期廣告報告中填充。包含不相符服務資料欄位的 PA 承載會離開陣列進入結構hci_conn的其餘部分。符合 BAA UUID 的漂移欄位會將這些位元組放在 iso_pi（sk）->base 中，使用者空間會使用 getsockopt（BT_ISO_BASE） 讀回這些位元組。每次反覆運算都從緩衝區結尾重新計算eir_len。（CVE-2026-89583）

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

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

  - platform/x86： ISST： 驗證邏輯 CPU ID 和 clos ID 驗證核心電源功能的最大 CLOS ID 和邏輯 CPU ID。拒絕任何大於支援上限的 clos 層級或邏輯 CPU 數目。這些用於計算 MMIO 偏移。（CVE-2026-89438）

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

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

  - i3c：瑞薩電子：修正 newdevs 遮罩的越界存取 當軟體啟動 DAA （動態位址分配） 時，控制器會透過 NRSPQP （正常回應佇列連接埠暫存器） 報告結果。回應描述元的資料長度欄位 （可透過 NRSPQP 暫存器存取） 指出 DAA 之後剩餘的裝置數目。因此，當匯流排為空時，此欄位包含控制器支援的最大裝置數量 （Renesas I3C 控制器為 8 個）。調整計算新探索到的裝置位遮罩的條件，以防止 I3C 匯流排為空時越界。（CVE-2026-89728）

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

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

  - nfsd：擴大nfsd_genl_rqstp位址欄位以sockaddr_storage結構nfsd_genl_rqstp將rq_daddr和rq_saddr宣告為純結構 sockaddr （16 位元組）。連線 IPv6 NFS 用戶端時，nfsd_genl_rpc_status_compose_msg（） 會將這些欄位轉換為結構 sockaddr_in6 * （28 位元組），並在位移 8..24 處讀取sin6_addr，這會從 16 位元組的 sockaddr 欄位結尾延伸 8 位元組，進入相鄰的 rq_flags 成員。然後，16 位元組的nla_put_in6_addr會透過 NFSD_A_RPC_STATUS_SADDR6/DADDR6 網路連結屬性，將 8 位元組的截斷 IPv6 位址，後面接著 8 位元組的rq_flags傳送至使用者空間。
    網路命名空間中的任何無特權處理程序都可以存取此問題，因為 NFSD_CMD_RPC_STATUS_GET 使用GENL_CMD_CAP_DUMP而不GENL_ADMIN_PERM。透過擴大結構sockaddr_storage的rq_daddr和rq_saddr來修復，以便 IPv6 轉換在範圍內運行，複製 memcpy 呼叫中的 sizeof（struct sockaddr_storage） 位元組以捕獲完整位址，以及零初始化 genl_rqstp 堆疊變數以防止透過 netlink 洩漏未初始化的尾部位元組。（CVE-2026-89698）

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

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

  - 在 libtiff 中發現一個瑕疵。「tiff2pdf」公用程式中存在堆積緩衝區溢位弱點，這是因為處理特製的 BigTIFF 檔案時發生整數截斷錯誤。攻擊者可以提供特製的 BigTIFF 文件，導致 64 位“StripByteCounts”值被截斷為 32 位整數。這會導致記憶體配置過小，以及隨後的越界記憶體複製，進而導致當機和嚴重的記憶體損毀。（CVE-2026-18495）

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

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

  - lockd， nfsd：RCU 保護nlmsvc_ops分派nlmsvc_ops由 nfsd_lockd_init（） 發布，並由 nfsd_lockd_shutdown（） 使用普通儲存區清除，而 lockd 則從 fs/lockd/svcsubs.c 中的分派網站解除參照。指標以 nfsd 的 .rodata 為目標，而 fopen/fclose 回呼位於 nfsd 的 .text 中，因此 rmmod nfsd 之後的過時載入會導致 NULL 解除參照或模組文字釋放後使用。
    將nlmsvc_ops宣告為__rcu，透過 rcu_assign_pointer（） 發布，透過 RCU_INIT_POINTER（） + synchronize_rcu（） 清除。將結構模組 *owner 欄位新增至nlmsvc_binding，並使用 try_module_get/module_put 將模組釘選到間接呼叫中。當綁定被拆除時，請回歸到 fput（） 以避免洩漏結構檔案參照。（CVE-2026-89709）

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

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

  - NFSD：在 NFSv4.0 撤銷狀態清理期間防止用戶端在釋放後使用 nfs40_clean_admin_revoked（） 在 clp->cl_lock 下獲取 stateid 參照，刪除 nn->client_lock，並調用 nfsd4_drop_revoked_stid（），後者透過 s->sc_client->cl_lock 解除參照 stateid 的用戶端。stateid 參照不會釘選用戶端，因此，在 nfsd4_drop_revoked_stid（） 仍在使用用戶端時，對捨棄的鎖定進行逐往的拆卸可以釋放用戶端。此清除作業會從自助洗衣店執行，因此定期掃描可能會因寫入 clients/<id>/ctl 檔案所驅動而爭用 force_expire_client（）。跳過已經到期的用戶端，否則在刪除鎖定之前將其釘選在 client_lock 下的cl_rpc_users，符合 nfsd4_revoke_states（）。（CVE-2026-89658）

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

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

  - ACPI：APEI：GHES：修正標頭後的 ARM 區段長度統計 在 ghes_handle_arm_hw_error（） 中，跳過帶有 （err + 1） 的 cper_sec_proc_arm 標頭後，剩餘長度會減少 sizeof（err） （指標大小） 而不是 sizeof（*err） （結構大小）。這會高估留給cper_arm_err_info記錄的位元組，而且當 err_info_num CPER 相對於 error_data_length 足夠大時，可能會讓剖析器讀取 CPER 區段。使用 sizeof（*err），以便長度統計符合指標前進和較早的 sizeof（*err） 大小檢查。（CVE-2026-89588）

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

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

  - iommu/sva：在顯示 SVA 控點之前設定 handle->dev iommu_attach_device_pasid（） 會在 iommu_sva_bind_device（） 傳回之前，在群組 PASID 查詢中安裝新的 SVA 附加控點。因此，並行繫結可以在卸除iommu_sva_lock之後尋找並重複使用相同的控制碼。handle->dev 是在丟棄 iommu_sva_lock 之後初始化的。這會留下一個視窗，爭用繫結可以傳回開發指標仍為 NULL 的控制碼。然後，後續的 iommu_sva_unbind_device（） 可以透過 handle->dev->iommu_group 取消參照它。在釋放 iommu_sva_lock 之前初始化 handle->dev，以便完全初始化任何可見的 SVA 控制碼。（CVE-2026-89451）

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

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

  - module：驗證字串表格區段類型 在elf_validity_cache_sechdrs中，除非區段類型為SHT_NULL或SHT_NOBITS，否則會驗證區段大小和位移。稍後，elf_validity_cache_secstrings和elf_validity_cache_index_str存取區段名稱資料表 （.shstrtab） 和符號字串資料表 （.strtab） 標頭，而不需要先確定其類型SHT_STRTAB。如果區段類型為 SHT_NULL 或 SHT_NOBITS，則sh_offset尚未經過驗證，而且在 elf_validity_cache_secstrings 或 elf_validity_cache_strtab 中取消參照時可能會參照越界記憶體。在快取這兩個字串區段標頭之前，先驗證它們是否為 SHT_STRTAB類型。（CVE-2026-89556）

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

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

  - wifi：rtl8xxxu：從 RX 完成路徑rx_urb_wq停止 rtl8xxxu ARM 修正 rx_urb_wq 的釋放後使用：rtl8xxxu_rx_complete（） 將 URB 交給 rtl8xxxu_queue_rx_urb（），後者將其排入 rx_urb_pending_list 上，一旦清單增長超過 RTL8XXXU_RX_URB_PENDING_WATER，就會排程rx_urb_wq。背景工作 rtl8xxxu_rx_urb_work（） 排空rx_urb_pending_list，透過 container_of 復原 priv，並透過 rtl8xxxu_submit_rx_urb（） 重新提交每個 URB，這會將其錨定在 rx_anchor 上，並取消參照 priv->udev。rtl8xxxu_stop（） 會取消同級工作項目 （c2hcmd_work、ra_watchdog、update_beacon_work），但絕不會取消rx_urb_wq，因此在 rtl8xxxu_disconnect（） 呼叫 ieee80211_free_hw（） 之後，在最後一次 RX 流量爆發期間武裝的背景工作者可以執行 rtl8xxxu_rx_urb_work（），這會釋放 priv，產生釋放後使用。視窗會在作用中的 RX 流量 （浮水印上方的擱置計數） 下開啟，然後中斷連線。有兩個拆卸爭用需要結束： * rtl8xxxu_queue_rx_urb（） 決定是否在 rx_urb_lock 下排入佇列，但在刪除鎖定後呼叫 schedule_work（）。觀察到 shutdown == false 並釋放鎖定的完成可以在 rtl8xxxu_stop（） 設定關機且 cancel_work_sync（） 已傳回之後呼叫 schedule_work（），讓背景工作在拆卸後執行。
    將 schedule_work（） 移動到相同的 ！shutdown 分支下，以便布防決策與關機檢查是不可部分完成的。* rtl8xxxu_rx_urb_work（） 透過 rtl8xxxu_submit_rx_urb（） 將其排空回 rx_anchor 的每個 URB 錨定。傳回 usb_kill_anchored_urbs（&priv->rx_anchor） 時仍在執行的工作會提交逸出終止的 URB。在 rtl8xxxu_stop（） 中，在終止之前呼叫 cancel_work_sync（&priv->rx_urb_wq），以便先耗盡工作者。在 rx_urb_lock 下設定 priv->shutdown 之後，完成就無法再排入佇列rx_urb_wq。然後，cancel_work_sync（） 會清空最後一個佇列或執行中的背景工作角色，而下列 usb_kill_anchored_urbs（） 會終止它可能已提交的 URB。涵蓋 rtl8xxxu_disconnect（） 是因為 ieee80211_unregister_hw（） 保證在 ieee80211_free_hw（） 釋放 priv 之前為即時介面執行 .stop（）。探查錯誤路徑不需要取消：rx_urb_wq在那裡INIT_WORK（），但無法排程，因為在 ieee80211_register_hw（） 成功之前不會提交任何 URB。此錯誤是透過靜態分析發現的。（CVE-2026-80947）

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

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

  - wifi： rtlwifi： rtl8192du： 修正 rtl92du_init_sw_vars（） 中可能的記憶體洩漏 rtl92du_init_shared_data（） 內配置的記憶體不會在 rtl92du_init_sw_vars（） 中的任何後續錯誤路徑中釋放。
    透過在錯誤路徑中新增對 rtl92du_deinit_shared_data（） 的呼叫來修正此問題。（CVE-2026-80942）

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

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

  - ALSA： bcd2000：在中斷連接時清除 URB 指標 bcd2000_free_usb_related_resources（） 會釋放兩個 URB 並將指標留在後面：usb_kill_urb（bcd2k->midi_out_urb）;usb_kill_urb（bcd2k->midi_in_urb）;
    usb_free_urb（bcd2k->midi_out_urb）;usb_free_urb（bcd2k->midi_in_urb）;rawmidi 設備比那次通話更耐用。拔除裝置時仍處於開啟狀態的子資料流會在關閉時從觸發路徑到達 bcd2000_midi_send（）。該函式會寫入釋放的 URB，然後將它傳遞至 USB 核心：
    bcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE;...ret = usb_submit_urb（bcd2k->midi_out_urb， GFP_ATOMIC）;usb_kill_urb（） 也不會停止稍後的提交，因此爭用中斷連線的提交可以在收割 URB 之後重新排入佇列。midi_in_urb以相同的方式公開：
    bcd2000_input_complete（） 會從完成處理常式重新提交它。7.2.0-rc5 （arm64） 上的 KASAN： 錯誤： KASAN：
    slab-use-after-free in bcd2000_midi_send [snd_bcd2000] 任務 bpoc/168 在 addr ffff00001827d388 寫入大小 4 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 由任務 168 釋放： usb_free_urb bcd2000_disconnect [snd_bcd2000] 錯誤： KASAN：usb_submit_urb 中的 slab-use-after-free 由任務 bpoc/168 在 addr ffff00001827d3b8 讀取大小 8 釋放後清除兩個指標並測試它們仍然可以運行的路徑。在釋放 URB 之前毒害它們：usb_poison_urb（） 會等候執行中的完成處理常式，並拒絕任何稍後的提交，因此在傳回之後，輸入路徑會靜止，而且只有 rawmidi 觸發路徑仍可到達 bcd2000_midi_send（） 。不需要解毒;URB 在下一行被釋放。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-80971）

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

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

  - ovl：修正 casefold-mismatch 路徑上的雙重 end_creating（） ovl_create_real當 casefold 一致性檢查失敗時，會釋放新的 dentry 兩次。S_IFDIR 分支調用 end_creating（） 並設定 err，然後落入 common out： 標籤，該標籤再次呼叫同一 dentry 上的 end_creating（）：案例 S_IFDIR：newdentry = ovl_do_mkdir（ofs， dir， newdentry， attr->mode）;err = PTR_ERR_OR_ZERO（newdentry）;if （！err &&; ofs->casefold ！= ovl_dentry_casefolded（Newdentry）） { pr_warn_ratelimited（...）;
    end_creating（紐德利特里）;/* 第一個 */ 錯誤 = -EINVAL;} 休息;...if （err） goto out;...out： if （err） {end_creating（newdentry）; /* 第二，相同的 dentry */ return ERR_PTR（err）; } end_creating（） 是 end_dirop（），它在父目錄上執行 inode_unlock（），在 dentry 上執行 dput（），因此父目錄的i_rwsem被解鎖兩次，dentry 被放置兩次。第二次解鎖釋放一個未持有的鎖，這是楔入該父項下的每個後續創建的內容，第二個 dput（） 會刪除一個從未被採用的引用。該分支由提交 dfc7da402ccc （ovl：建立新齒列時檢查大小寫一致性） 新增為裸 dput（），該分支已兩次釋放參照;commit fe497f0759e0 （VFS：將 vfs_mkdir（） 更改為失敗時解鎖。已將兩個網站轉換為 end_creating（），並新增雙重解鎖。無特權的使用者可存取此問題。在 ovl_parse_layer（） 中裝載時驗證層的摺疊一致性，並在 ovl_lookup_single（） 中的每次查詢時再次驗證，但 ofs->workdir 是在使用者提供的 workdir 內建立的內部工作子目錄，並且不會重新檢查該子目錄。
    因此，在掛載後將其標記為 casefolded 會使每個 ovl_create_temp（） 繼承錯誤的狀態 - 並且該路徑通過 ovl_start_creating_temp（） 到達 ovl_create_real（），它使用帶有生成名稱的 start_creating（），因此永遠不會運行查找時間檢查。unshare -Urm mount -t tmpfs -o casefold=utf8-12.1.0 tmpfs mnt mkdir -p mnt/lower/d mnt/upper mnt/work mnt/merged mount -t overlay ovl -o lowerdir=mnt/lower，\ upperdir=mnt/upper，workdir=mnt/work mnt/merged chattr +F mnt/work/work mkdir mnt/merged/d/sub # 目錄複製 overlayfs： 錯誤的繼承 casefold （work/#5） 和下一個複製區塊永遠在父項的i_rwsem上： mkdir D start_creating+0x65/0xb0 ovl_start_creating_temp+0xb0/0xe0 [覆蓋] ovl_create_temp+0xa3/0x1d0 [覆蓋] ovl_copy_up_one+0x1f1c/0x21c0 [覆蓋] ovl_copy_up_flags+0xf5/0x140 [覆蓋] ovl_create_object+0xb7/0x220 [覆蓋] ovl_mkdir+0x23/0x40 [覆蓋] 從分支中刪除 end_creating（） 並釋放：擁有清理， 這是此函式中的所有其他錯誤路徑已經執行的動作。（CVE-2026-89767）

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

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

  - libnvdimm/labels：防止 __nd_label_validate（） 中的整數溢位 媒體名稱空間索引欄位 nslot 是從 DIMM 標籤儲存區讀取的 u32。__nd_label_validate（） 將其與組態區域大小為界，但 sizeof_namespace_label（） 傳回 unsigned，因此乘積 nslot * label_size 以 32 位元評估，並在比較前以模 2^32 包裝。特製的 nslot 通過邊界，然後用作 nd_label_data_init（） 中的迴圈跳脫計數，其 memset（） 從config_size緩衝區的末尾走出：越界寫入。該欄位不受信任——它來自媒體，或透過ND_CMD_SET_CONFIG_DATA來自使用者空間。以 64 位元評估產品，以便綁定檢查準確無誤;符合規範的標籤不受影響。由提交 4a826c83db4e 引入時，檢查是安全的 （libnvdimm：命名空間索引：
    讀取並驗證）：它乘以 sizeof（struct nd_namespace_label），一個size_t，因此在 64 位元構建中，產品沒有包裝。提交 564e871aa66f （libnvdimm，標籤：新增 v1.2 nvdimm 標籤定義） 當標籤大小變成透過 sizeof_namespace_label（） 讀取的執行階段值時，將其縮小為 32 位元。
    (CVE-2026-89559)

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

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

  - net： ravb：避免取消參照無效的 PTP 時鐘 PTP 時鐘在第一次開啟之前不可用，因此查詢其索引可能會取消參照 NULL 指標。註冊失敗也可能在 priv->ptp.clock 中留下錯誤指標。分別快取 PHC 索引，並在未註冊時鐘時報告 -1。將註冊錯誤正規化為 NULL 並保留靜態時間戳記功能。（CVE-2026-80992）

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

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

  - wifi： iwlwifi： dvm：修正 iwl_op_mode_dvm_start（） 中的記憶體洩漏 在 iwl_op_mode_dvm_start（） 中，跳轉到 out_free_eeprom 目前會繞過out_free_eeprom_blob標籤。因此，在成功剖析 EEPROM 釋放 priv->nvm_data但洩漏 priv->eeprom_blob 後觸發錯誤路徑。透過重新排序錯誤處理標籤來修正此記憶體洩漏，以便out_free_eeprom失敗為 out_free_eeprom_blob。該錯誤首先是由我們在分析 v6.13-rc1 時針對核心記憶體管理錯誤開發的實驗性分析工具標記的。該工具仍在開發中，尚未公開。手動檢查確認該錯誤在 v7.1-rc6 中仍然存在。x86_64 allyesconfig 組建沒有顯示新的警告。由於我們不支援英特爾 DVM 無線硬體和韌體進行測試，因此無法執行運行時測試。（CVE-2026-80948）

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

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

  - WIFI：MT76：MT7925：在多鏈路省電設定期間，取消停止 MT7925 佇列時的 mlo_pm_work，mlo_pm_work延遲 5 秒，並且絕不在停止路徑上取消。如果裝置在該視窗內被拆除，則工作會比拆解時間更長，之後會觸發其計時器，嘗試排入已消失的工作佇列：工作佇列：無法在 wq phy0 上排入佇列 mt7925_mlo_pm_work [mt7925_common] 警告：
    kernel/workqueue.c：2283 在 __queue_work+0x59/0xa0， CPU#1：swapper/1/0 call_timer_fn+0x2a/0x140
    __run_timers+0x203/0x330 run_timer_softirq+0x86/0xf0 MT7921 已經有自己的停止回呼，因此請在呼叫 mt792x_stop（） 之前為 mt7925 新增一個取消工作的回呼。mt7925_ops支援 PCIe 和 USB 驅動程式，因此涵蓋兩者。（CVE-2026-80936）

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

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

  - btrfs：修正 NOCOW 直接 I/O 寫入 btrfs_dio_iomap_begin（） 呼叫 btrfs_get_extent（） 中的範圍對映洩漏，其傳回必須在所有結束路徑上捨棄的範圍對映參照。對於直接寫入 NOCOW 範圍，btrfs_get_blocks_direct_write（） 會繼續使用該範圍對應，並要求 btrfs_create_dio_extent（） 配置排序範圍。如果失敗，例如因為 btrfs_alloc_ordered_extent（） 失敗，則函式會傳回錯誤，而不會捨棄輸入範圍對應。
    PREALLOC 路徑會先捨棄輸入範圍地圖，然後再將其替換為新建立的範圍地圖，藉此避免這種情況。在取代對應之前檢查 btrfs_create_dio_extent（） 中的錯誤，並在失敗時捨棄輸入範圍對應。（CVE-2026-89644）

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

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

  - fs/ntfs3：在記錄重播時驗證髒頁表 每個DIR_PAGE_ENTRY都以一個 page_lcns[] 陣列結束，其長度是磁碟上的lcns_follow欄位。 check_rstbl（） 會驗證表格簿記，但從不檢查此陣列是否適合項目，因此特製的lcns_follow會讓 v0->v1 轉換 memmove 和後續的重播通道從項目中執行。新增 check_dp_table（） 以在 check_rstbl（） 之後透過 struct_size（） 拒絕任何大於其大小聲明的項目 （用於分配這些項目的相同表達式，因此檢查在構造上是溢位安全的）。然後，所有消費者都可以信任lcns_follow作為真正的容量。
    這涵蓋了索引受項目本身限制的每個 page_lcns[] 存取 （轉換 memmove、透過 find_dp（） 的 HotFix 儲存區，以及自界掃描迴圈）。其索引來自日誌記錄的存取需要單獨的繫結，並在後續修補程式中處理。（CVE-2026-89617）

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

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

  - ALSA： serial-u16550：在探測時檢查卡片索引有效性 serial-u16550 驅動程式會盲目信任指定的 devptr->id 值在探測時的適當卡片索引範圍內。驅動程式本身在模組探測時建立的裝置沒問題，但如果裝置是透過 sysfs 介面手動綁定的，則可能是
    -1 設定為 none，這會導致 index[] 和其他參數的 OOB 存取。新增卡片索引的健全性檢查，並在值超出範圍時警告/更正。（CVE-2026-80965）

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

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

  - platform/x86： dell-wmi-sysman： Don't hex dump 屬性安全性緩衝區 set_attribute（） 會透過 populate_security_buffer（） 以目前的管理員密碼填入 BIOS 屬性要求緩衝區的安全區域，然後使用 print_hex_dump_bytes（） 傾印整個要求緩衝區。這可能會在核心記錄中暴露純文字管理員密碼。透過提交 d1a196e0a6dc （platform/x86： dell-wmi-sysman： 不要十六進位轉儲純文字密碼資料），修正了密碼屬性路徑的相同問題。
    從 BIOS 屬性路徑移除剩餘的傾印。（CVE-2026-89444）

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

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

  - aiosmtplib 之前 5.1.3 無法正確驗證呼叫者提供的電子郵件地址，允許攻擊者將 ESMTP 參數插入 MAIL FROM 和 RCPT TO 命令列。攻擊者可以製作包含空格和尖括號的惡意位址，將 AUTH、NOTIFY 或 ORCPT 等參數附加到信封命令中，偽造經過身份驗證的身分或強制向第三方發送傳送通知。
    (CVE-2026-90467)

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

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

  - xdp：修正零拷貝框架佈局 xdp_convert_zc_to_xdp_frame（） 將 XSK 封包複製到 order-0 頁面中，並將PAGE_SIZE通告為其框架大小。它允許複製的框架佔據skb_shared_info所需的頁尾，即使元數據將幀標頭與數據包數據分開，也記錄零空間。
    因此，透過 cpumap 重新導向的AF_XDP零拷貝封包可能會使 skb 重疊skb_shared_info或將其放置在分配的頁面之外。將複製的版面配置限制為 SKB_WITH_OVERHEAD（PAGE_SIZE），並將中繼資料長度包含在框架餘量中。重新導向呼叫端已處理 NULL 轉換結果。錯誤：
    KASAN：任務 cpumap/1/map：1/146 在 addr ffff88800cf37004 處寫入大小為 4 的 KASAN：slab-out-of-bound skb_gro_receive s 呼叫追蹤：skb_gro_receive （net/core/gro.c：174） udp_gro_receive （net/ipv4/udp_offload.c：812） inet_gro_receive （net/ipv4/af_inet.c：1539） dev_gro_receive （net/core/gro.c：515） gro_receive_skb （net/core/gro.c：633） cpu_map_kthread_run （kernel/bpf/cpumap.c：395） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：164） ret_from_fork_asm （arch/x86/entry/entry_64.S：255） 核心錯誤 - 未同步： KASAN：panic_on_warn設定...（CVE-2026-81002）

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

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

  - platform/x86/amd/pmc：傳播 SMU 錯誤並驗證 S2D 位址 amd_stb_s2d_init（） 捨棄數個 S2D SMU 命令的傳回值。當 SMU 拒絕命令時 （例如 SMU cmd failed. err： 0xff），系統只會間接注意到失敗 （如果有的話），並報告為 -EIO，以掩蓋真正的錯誤。更嚴重的是，S2D_PHYS_ADDR_LOW/HIGH 傳回值被忽略，因此在失敗時 phys_addr_low/hi 保持未初始化狀態，並將組裝的位址直接傳遞給 devm_ioremap（）。當 SMU 將它們保留為零時，這會對應實體位址 0 並觸發 ioremap-on-RAM 警告：amd_pmc AMDI000B：00：SMU cmd 失敗。錯誤：0x0000000000000000 處的 RAM 上0xff ioremap - 0x0000000000ffffff 警告：arch/x86/mm/ioremap.c 處的 CPU：13 PID：4592：... 檢查每個 SMU 命令的傳回值並傳播它，並在呼叫 devm_ioremap（） 之前拒絕零實體位址。（CVE-2026-81016）

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

ID	名稱	嚴重性
345274	Linux Distros 未修補弱點：CVE-2026-89733	high
345273	Linux Distros 未修補弱點：CVE-2026-89551	critical
345272	Linux Distros 未修補弱點：CVE-2026-80998	high
345271	Linux Distros 未修補弱點：CVE-2026-89655	critical
345270	Linux Distros 未修補弱點：CVE-2026-80943	high
345269	Linux Distros 未修補弱點：CVE-2026-89517	medium
345268	Linux Distros 未修補弱點：CVE-2026-54258	medium
345267	Linux Distros 未修補弱點：CVE-2026-89520	high
345266	Linux Distros 未修補弱點：CVE-2026-89648	high
345265	Linux Distros 未修補弱點：CVE-2026-89545	high
345264	Linux Distros 未修補弱點：CVE-2026-89446	high
345263	Linux Distros 未修補弱點：CVE-2026-89768	low
345262	Linux Distros 未修補弱點：CVE-2026-89638	high
345261	Linux Distros 未修補弱點：CVE-2026-80970	high
345260	Linux Distros 未修補弱點：CVE-2026-89501	high
345259	Linux Distros 未修補弱點：CVE-2026-89465	high
345258	Linux Distros 未修補弱點：CVE-2026-89755	high
345257	Linux Distros 未修補弱點：CVE-2026-89623	high
345256	Linux Distros 未修補弱點：CVE-2026-22590	critical
345255	Linux Distros 未修補弱點：CVE-2026-89762	high
345254	Linux Distros 未修補弱點：CVE-2026-89598	high
345253	Linux Distros 未修補弱點：CVE-2026-89548	high
345252	Linux Distros 未修補弱點：CVE-2026-80967	high
345251	Linux Distros 未修補弱點：CVE-2026-89480	high
345250	Linux Distros 未修補弱點：CVE-2026-22591	high
345249	Linux Distros 未修補弱點：CVE-2026-89583	high
345248	Linux Distros 未修補弱點：CVE-2026-89438	medium
345247	Linux Distros 未修補弱點：CVE-2026-89728	high
345246	Linux Distros 未修補弱點：CVE-2026-89698	medium
345245	Linux Distros 未修補弱點：CVE-2026-18495	medium
345244	Linux Distros 未修補弱點：CVE-2026-89709	high
345243	Linux Distros 未修補弱點：CVE-2026-89658	critical
345242	Linux Distros 未修補弱點：CVE-2026-89588	high
345241	Linux Distros 未修補弱點：CVE-2026-89451	medium
345240	Linux Distros 未修補弱點：CVE-2026-89556	high
345239	Linux Distros 未修補弱點：CVE-2026-80947	high
345238	Linux Distros 未修補弱點：CVE-2026-80942	medium
345237	Linux Distros 未修補弱點：CVE-2026-80971	high
345236	Linux Distros 未修補弱點：CVE-2026-89767	high
345235	Linux Distros 未修補弱點：CVE-2026-89559	high
345234	Linux Distros 未修補弱點：CVE-2026-80992	high
345233	Linux Distros 未修補弱點：CVE-2026-80948	medium
345232	Linux Distros 未修補弱點：CVE-2026-80936	high
345231	Linux Distros 未修補弱點：CVE-2026-89644	high
345230	Linux Distros 未修補弱點：CVE-2026-89617	high
345229	Linux Distros 未修補弱點：CVE-2026-80965	high
345228	Linux Distros 未修補弱點：CVE-2026-89444	high
345227	Linux Distros 未修補弱點：CVE-2026-90467	medium
345226	Linux Distros 未修補弱點：CVE-2026-81002	critical
345225	Linux Distros 未修補弱點：CVE-2026-81016	high

偵測

Nessus 的 Misc. 系列

high

critical

high

critical

high

medium

medium

high

high

high

high

low

high

high

high

high

high

high

critical

high

high

high

high

high

high

high

medium

high

medium

medium

high

critical

high

medium

high

high

medium

high

high

high

high

medium

high

high

high

high

high

medium

critical

high