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

  - netfs：修正 ->remote_i_size 和 ->zero_point 中潛在的撕裂 修正使用
    ->remote_i_size 和 ->zero_point，方法是複製 i_size_read（） 和 i_size_write（） 並使用與 i_size 相同的 seqcount。我們需要確保 netfslib 和使用它的文件系統在更新任何大小時始終保持i_lock，以防止i_size_seqcount損壞。（CVE-2026-64160）

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

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

  - af_unix：修正 unix_stream_data_wait（） 中 tail->len 的 UAF 讀取 unix_stream_data_wait（） 會執行 skb_peek_tail（&sk->sk_receive_queue），而不保留任何防止該佇列上的 SKB 出列和釋放的鎖定。自提交 79f632c71bea 以來，情況一直如此（unix/stream：修正偏移量大於佇列中資料的窺視）。這樣做的第一個後果是，即使 'last' 在語義上指的是已經釋放的 SKB，而 'tail' 是分配在相同位址的新 SKB，指標比較 'tail ！= last' 也可能為假;這可能會導致 unix_stream_data_wait（） 在新資料到達後錯誤地繼續阻塞，但僅限於一個奇怪的情況，即同一通訊端上的窺視 recv（） 和正常的 recv（） 正在競爭，這可能不是一個真正的問題。但由於提交 2b514574f7e8 （net： af_unix：
    實作串流af_unix通訊端的拼接），'tail' 實際上被取消參照，這可能會導致在以下爭用場景中出現 UAF（其中 test_setup（） 以單執行緒運行，然後 test_thread1（） 和 test_thread2（） 在兩個執行緒中同時運行： ''' static int socks[2]; void test_setup（void） {socketpair（AF_UNIX， SOCK_STREAM， 0， socks）; send（socks[1]， A， 1, 0);int peekoff = 1;
    setsockopt（socks[0]， SOL_SOCKET， SO_PEEK_OFF， &peekoff， sizeof（peekoff））;} void test_thread1（void） { char dummy; recv（socks[0]， &dummy， 1， MSG_PEEK）; } void test_thread2（void） { char dummy; recv（socks[0]， &dummy， 1， 0）; shutdown（socks[1]， SHUT_WR）; } ''' when racing like this： ''' thread1 thread2 unix_stream_read_generic mutex_lock（&u->iolock） skb_peek（&sk->sk_receive_queue） skb_peek_next（skb， &sk->sk_receive_queue） mutex_unlock（&u->iolock） unix_stream_read_generic unix_state_lock（sk） skb_peek（&sk->sk_receive_queue） unix_state_unlock（sk） unix_stream_data_wait unix_state_lock（sk） tail = skb_peek_tail（&sk->sk_receive_queue） spin_lock（&sk->sk_receive_queue.lock） __skb_unlink（skb， &sk->sk_receive_queue） spin_unlock（&sk->sk_receive_queue.lock） consume_skb（skb） [釋放 SKB] 'tail ！= last'： false 'tail'： true 'tail->len ！= last_len' ***UAF*** ''' 透過移除 tail->len 的讀取來修正 UAF;只有在 UNIX 通訊端接收佇列中的 SKB 可以增長時，檢查 tail->len 才有意義，這種情況不再發生。Kuniyuki 解釋說：> 當提交 869e7c62486e （net：af_unix：實作串流 sendpage >支援） 新增 sendpage（） 支援時，資料可以附加到接收者佇列中的最後一個> skb。> > 這就是為什麼我們需要在 unix_stream_data_wait（） 中等待新資料時檢查最後一個 skb 的長度是否>更改。> > 但是，提交 a0dbf5f818f9 （af_unix：支援 MSG_SPLICE_PAGES） 並>提交 57d44a354a43 （unix：轉換 unix_stream_sendpage（） 以使用 > MSG_SPLICE_PAGES） 重構 sendmsg（），現在資料一律會>新 skb 中新增。這表示此修正不適用於之前 6.5的核心。（CVE-2026-64109）

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

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

  - ProFTPD mod_sftp包含經驗證的 SFTP 使用者可連線的堆積型緩衝區溢位。fxp_packet_read（） 函式接受攻擊者提供的 32 位元大端 SFTP 封包長度，而無需進行最低可用性檢查。值為 0 會導致讀取路徑中其他位置的未帶正負號減法反向溢位至大約 4 GB。該過大的請求到達核心記憶體分配器，其中四捨五入的大小以 size_t 計算，但以 32 位元 int 的形式傳遞給 new_block（）;0x100000000的低 32 位元為 0，因此 new_block（） 傳回一個小 （~512 位元組） 區塊，同時呼叫者被告知它收到了 ~4 GB。接著，後續的填充迴圈會將攻擊者控制的位元組串流到 544 位元組配置的結尾，從而產生攻擊者控制的堆積緩衝區溢位。經驗證的使用者可以使用單一格式錯誤的 SFTP 封包 （packet_len=0 後面接著大於大約 544 位元組的內文） 視需要使每個連線的 ProFTPD 工作階段子項當機，從而產生可靠的已驗證遠端拒絕服務。視堆積配置和相鄰配置而定，可能會發生堆積中繼資料損毀，以及拒絕服務以外的進一步後果，不過提供的概念證明只會證明拒絕服務。
    (CVE-2026-53994)

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

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

  - net： bcmgenet：保持 RBUF EEE/PM 停用 設定RBUF_EEE_EN |一旦 MAC EEE 處於活動狀態，RBUF_ENERGY_CTRL中的RBUF_PM_EN就會中斷 GENET 硬體上的 RX 路徑。當鏈路保持啟動且通常的描述元/RX 錯誤計數器保持靜音時，RX 流量會停止流動。在該狀態下，MAC仍接受幀（rbuf_ovflow_cnt不斷攀升），但RBUF不再將它們轉發到DMA，因此rx_packets不再在netdev級別遞增。在某些板上，損毀最終會透過 LPI 退出的 bcmgenet_rx_poll skb_release_data中的分頁錯誤。在 Pi 4B （BCM2711 + BCM54213PE） 上複製，並由 Florian Fainelli 在具有相同崩潰簽名的內部 Broadcom 4908 系列板上確認。
    RBUF_PM_EN沒有公開記錄。現在 phy_support_eee（） 預設啟用 EEE，這種情況更頻繁地出現，但一旦透過 ethtool 開啟 TX LPI，它也會影響較舊的核心，因此它並不特定於最近的變更。始終清除RBUF_EEE_EN |RBUF_PM_EN bcmgenet_eee_enable_set，因此位元在重設期間保持關閉狀態。UMAC 和 TBUF 設定不理會，因此 TX 端 EEE 會繼續運作。（CVE-2026-64125）

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

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

  - 已解決 Linux 核心中的下列弱點：nvme: fix bio leak on mapping failure The local bio is always NULL, so we'd leak the bio if the integrity mapping failed. Just get it directly from the request. (CVE-2026-64072)

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

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

  - vsock/vmci：修正對等體在交握期間重設連線時的 UAF vmci_transport_recv_connecting_server（） 針對其預設交換器臂中的對等 RST 傳回 err = 0：err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ？0 ： -EINVAL;這使得 vmci_transport_recv_listen（） 跳過 vsock_remove_pending（），將擱置的通訊端留在接聽程式的pending_links上，並顯示 sk_state = TCP_CLOSE，而 destroy： 仍然刪除了在 schedule_delayed_work（） 之前獲取的顯式引用。一秒鐘後，vsock_pending_work（） 觀察到 is_pending=true 並執行完整清理：
    vsock_remove_pending（） 然後是兩個尾隨的 sock_put（sk） 呼叫 -- 第一個達到 refcount 0 和
    __sk_freed通訊端，第二個寫入釋放的物件： 錯誤：KASAN：refcount_warn_saturate 中的 slab-use-after-free 由任務 kworker 在 addr ffff88800b1cac80 寫入大小為 4 的工作佇列：事件 vsock_pending_work 將對等 RST 視為任何其他意外封包類型 （err = -EINVAL）。所有 destroy： arms 現在傳回錯誤 < 0，因此 vmci_transport_recv_listen（） 同步從 pending_links 中刪除 pending ，而 vsock_pending_work（） 採用 is_pending=false / ！rejected 分支，僅刪除自己的工作參照。
    這也關閉了 Sashiko 在 v2 上報告的多封包爭用：在任何後續封包找到它之前，擱置將從清單中刪除。Sashiko 也指出的 vmci_transport_recv_listen（） 的錯誤< 0 路徑上預先存在的 sk_acceptq_removed（） 間隙並未在此修補程式中引入或更改。使用 KASAN 在 lts-6.12.79 上測試：52/100 未修補 -> 0/100 已修補。（CVE-2026-64115）

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

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

  - ntfs3：拒絕直接使用者空間寫入保留 $LX的 * xattrs NTFS3 使用 $LXUID、 $LXGID和 $LXMOD$LXDEV 作為內部 WSL 權限中繼資料，並從 ntfs_get_wsl_perm（） 重新載入到 i_uid、i_gid 和 i_mode。由於空前綴 xattr 處理常式也允許檔案擁有者直接在這些名稱上呼叫 setxattr（），因此可寫入 ntfs3 掛載上的無權限寫入器可以在自己的檔案上植入根擁有權和S_ISUID，並在 inode 重新載入後獲得 euid 0。拒絕直接使用者空間寫入保留 $LX的 * 名稱。內部 ntfs3 中繼資料更新不會變更，因為 ntfs_save_wsl_perm（） 會直接透過 ntfs_set_ea（） 寫入這些更新。[almaz.alexandrovich@paragon-software.com：新增了針對非特權使用者的額外檢查]（CVE-2026-63833）

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

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

  - hdlc_ppp：在釋放 hdlc 狀態之前同步每個原型計時器 結構 ppp 中嵌入的每個 PPP 控制協定 （LCP/IPCP/IPV6CP） 都會透過 timer_setup（） 註冊計時器。該結構 ppp 是 hdlc->state 分配，detach_hdlc_protocol（） 在兩個拆卸路徑中使用 kfree（） 釋放：unregister_hdlc_device（） 和 attach_hdlc_protocol（） 內部的重新附加。ppp 原型從未註冊過 .detach 回呼，因此 detach_hdlc_protocol（） 在 kfree（） 之前不執行計時器同步。ppp_cp_event（） 中唯一的取消 timer_delete（&proto->timer） 是部分的（它不等待正在運行的回呼），並且僅在 ->CLOSED 轉換時運行;ppp_stop（）/ppp_close（） 也不同步。已執行的 ppp_timer 回呼 （在 ppp->lock 上被阻止） 在 kfree 中倖存下來，然後在釋放的記憶體中取消參照 proto->state / ppp->lock，從而導致釋放後使用。透過新增一個 .detach 協助程式來解決此問題，該協助程式會在每個原型計時器上呼叫 timer_shutdown_sync（）。detach_hdlc_protocol（） 會在 kfree（hdlc->state） 之前叫用 proto->detach（dev），因此 timer_shutdown_sync（） 現在在兩個自由路徑上都運行。使用 timer_shutdown_sync（） 而不是 timer_delete_sync（），因為 keepalive 路徑會透過 add_timer（）/mod_timer（） 重新布防計時器，並在拆卸期間封鎖關機封鎖任何重新啟用。當附加通訊協定時，初始化 ppp_ioctl（） 中的每個通訊協定計時器，並從 ppp_start（） 中移除現在冗餘的 timer_setup（），以便計時器在附加時只初始化一次，並且 ppp_timer_release（） 永遠不會在未初始化的timer_list結構上運作。attach_hdlc_protocol（） 使用 kmalloc（） （而不是 kzalloc），因此 struct ppp 的 protos[i].timer 在第一個 timer_setup（） 之前是未初始化的垃圾;如果沒有此 init-at-attach，在從未啟動設備的情況下附加 PPP 協議將使 timer_shutdown_sync（） 在 .detach 中的未初始化記憶體上運行。將初始化從 ppp_start（） （僅在 NETDEV_UP 上執行） 移至附加路徑，會使初始化無條件，並避免兩次初始化相同的timer_list。此錯誤是透過靜態分析發現的。（CVE-2026-63803）

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

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

  - fbdev： fbcon：修正 fbcon_do_set_font（） err_out中的越界讀取 當 fbcon_do_set_font（） 失敗時（例如，由於 vc_resize（） 內部記憶體配置失敗，記憶體壓力很大），它會跳到「err_out」標籤以回滾主控台狀態。然而，目前的復原邏輯忘記還原「hi_font」狀態，導致嚴重的狀態機器損毀。在函式的前面，可能會呼叫「set_vc_hi_font（）」來變更「vc->vc_hi_font_mask」並改變螢幕緩衝區。如果「vc_resize（）」隨後失敗，「err_out」路徑會還原「vc_font.charcount」，但完全跳過復原「vc_hi_font_mask」和螢幕緩衝區。此不相符會使終端機處於不同步狀態。
    因為 'vc_hi_font_mask' 仍會設定，所以 VT 子系統仍會接受來自使用者空間的大於 255 的字元索引，並將它們寫入螢幕緩衝區。後續的轉譯呼叫 （例如，'fbcon_putcs（）'） 接著會使用這些膨脹的索引來存取還原的 256 個字元字型陣列，進而導致確定性越界讀取和潛在的核心記憶體洩漏。透過在錯誤路徑中新增「hi_font」遮罩和螢幕緩衝區缺少的復原邏輯來修正此問題。（CVE-2026-53402）

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

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

  - drm/amdgpu/jpeg：設定 JPEG v2.5 環的no_user_fence JPEG 環不支援 64 位元使用者圍欄寫入，拒絕帶有使用者圍欄的 CS 提交。（從提交 3216a7f4e2642bda5fd14f57586e835ae9202587 中挑選）（CVE-2026-63847）

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

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

  - bpf：將 kvfree（） 用於已取代的 sysctl 寫入緩衝區 proc_sys_call_handler（） 會使用 kvzalloc（） 配置其暫存 sysctl 緩衝區，並將它傳遞給 __cgroup_bpf_run_filter_sysctl（）。由於 kvzalloc（） 可能會回歸到 vmalloc（） 進行大型配置，因此使用 kfree（） 釋放該緩衝區是錯誤的，並且可能會損毀記憶體。使用 kvfree（） 安全地處理 kmalloc 和 kvzalloc（）/vmalloc 分配。該錯誤首先是由我們在分析 v6.13-rc1 時針對核心記憶體管理錯誤開發的實驗性分析工具標記的。
    該工具仍在開發中，尚未公開。手動檢查確認該錯誤在 v7.1-rc5 中仍然存在。在啟用 KASAN 和 CONFIG_FAILSLAB 啟動的 QEMU 客體中重現了基於 v7.1-rc4 的錯誤x86_64。為了執行取代路徑，測試樹狀結構也包含 __cgroup_bpf_run_filter_sysctl（） 中過時 ret == 1 檢查的隨附修正。複製程式將 failslab 插入限制在 proc_sys_call_handler（） 範圍內，使用 stacktrace-depth=32，並插入 fail-nth=1，同時從目標 cgroup 中的任務寫入 8191 位元組至 /proc/sys/kernel/domainname。在該設定下，fail-nth=1 觸發了錯誤： 錯誤：無法處理位址的頁面錯誤：ffffeb0200024d48 #PF：
    核心模式下的主管讀取存取權 #PF：error_code（0x0000） - 不存在頁面 PGD 0 P4D 0 哎呀：哎呀：
    0000 SMP KASAN NOPTI CPU：2 UID：0 PID：209 通訊：repro_proc_sys_ 未受污染 7.1.0-rc4-00686-g97625979a5d4 搶佔（延遲） 硬體名稱：QEMU 標準 PC （Q35 + ICH9， 2009），BIOS 1.15.0-1 04/01/2014 RIP：0010：kfree+0x6e/0x510 ... 通話追蹤： <TASK> ？
    __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ？
    __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ？srso_return_thunk+0x5/0x5f ？
    __kvmalloc_node_noprof+0x345/0x870 ？proc_sys_call_handler+0x250/0x480 ？srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ？__pfx_proc_sys_call_handler+0x10/0x10 ？srso_return_thunk+0x5/0x5f ？selinux_file_permission+0x39f/0x500 ？srso_return_thunk+0x5/0x5f ？lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ...</TASK> 在相同的測試設定上套用此修正後，以 fail-nth=1 重新執行再現器不會產生對應的 Oops 報告。（CVE-2026-63809）

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

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

  - exfat：修正 exfat_find_dir_entry（） 中潛在的釋放後使用問題 在 exfat_find_dir_entry（） 中，從 exfat_get_dentry（） 獲得的buffer_head會隨著 brelse（bh） 一起釋放，然後 fall-through TYPE_EXTEND 分支透過 ep 讀取目錄項目 （指向 bh->b_data）： brelse（bh）;if （entry_type == TYPE_EXTEND） { ...len = exfat_extract_uni_name（ep， entry_uniname）;... }在 brelse（） 刪除我們的引用後，沒有任何保證支持 bh->b_data 的基礎頁面對於後續的 exfat_extract_uni_name（） 讀取仍然有效。這與提交 fc961522ddbd 中修正的模式相同 （exfat：修正 exfat_load_upcase_table（）） 中的釋放後潛在使用。移動 brelse（bh），使其在每個分支上不再取消參照 ep 後執行。在 QEMU x86_64上確認，在 linux-next 上使用 CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y，使用特製的 exFAT 映像（具有相同雜湊衝突的長檔案名強制TYPE_EXTEND路徑）。在 brelse（bh） 和 ep 讀取之間插入僅除錯 invalidate_bdev（） 以使過時解除參照視窗具有確定性，未修補的核心錯誤： 錯誤：KASAN：
    exfat_find_dir_entry+0x133b/0x15a0 中的釋放後使用 錯誤：無法處理位址的頁面錯誤：
    ffff88801a5fa0c2 哎呀：0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP：
    0010：exfat_find_dir_entry+0x1188/0x15a0 套用此修補程式後，相同的儀表線束會在同一個清理器堆疊下乾淨地完成。我沒有在普通回收下重現未檢測內核的崩潰;檢測的 A/B 建立了存留期違規，並且修補程式將其關閉，而不是未經協助的可觸發性聲明。（CVE-2026-63808）

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

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

  - drm/amdgpu：在配置時零初始化 GART 表格 GART TLB 在取消對應後會排清，但在對應後不會排清。由於 amdgpu_bo_create_kernel（） 不會對緩衝區進行零初始化，因此當寫入單一 PTE 時，TLB 可能會推測地從相同的快取行載入其他未初始化的項目。這些垃圾項目可能看起來有效，而後續寫入相同快取行中的另一個 PTE 可能會導致 GPU 使用來自 TLB 的過時垃圾 PTE。透過呼叫 memset_io（） 在配置後立即使用 gart_pte_flags 初始化 GART 表來解決此問題。使用 AMDGPU_GEM_CREATE_VRAM_CLEARED，基於 SDMA 的清除將無法運作，因為 SDMA 需要初始化 GART 才能運作。（從提交 d9af8263b82b6eaa60c5718e0c6631c5037e4b24 中挑選）（CVE-2026-53374）

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

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

  - net：airoha：在 airoha_qdma_cleanup_tx_queue（） 中新增缺少的位元 與 airoha_qdma_cleanup_rx_queue（） 類似，在airoha_qdma_cleanup_tx_queue常式中重設 DMA TX 描述元。此外，將TX_DMA_IDX重設為 TX_CPU_IDX，以通知 NIC QDMA TX 環為空。（CVE-2026-63859）

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

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

  - NFSv4/pNFS：拒絕 nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr（） 中的零長度r_addr從 GETDEVICEINFO 多路徑 DS 內文解碼 netaddr4 的r_netid和r_addr不透明，然後立即呼叫 strrchr（buf， '.'） 來尋找連接埠分隔符號。兩種解碼都使用 xdr_stream_decode_string_dup（），目前程式碼在取消引用傳回的字串之前僅檢查 nlen < 0 / rlen < 0。當線上不透明的長度為零時，xdr_stream_decode_opaque_inline（） 傳回 0，xdr_stream_decode_string_dup（） 落入其 *str = NULL;傳回 ret 尾部，保留 buf NULL，傳回值為 0。< 0 檢查無法擷取此問題，而下一行是 strrchr（NULL， '.'），這是核心 NULL 指標解除參照，可從針對惡意或已入侵的中繼資料伺服器掛載的任何 pNFS-flexfile 用戶端存取。明確拒絕零長度大小寫，讓解碼器以 -EBADMSG 失敗 （視為格式錯誤的 GETDEVICEINFO 內文），而不是讓用戶端錯亂。（CVE-2026-53391）

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

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

  - drm/amdgpu/vcn：設定 VCN v3.0 enc/dec 環的no_user_fence VCN 編碼器和解碼器環不支援 64 位元使用者柵欄寫入，拒絕具有使用者柵欄的 CS 提交。（從提交 663bed3c7b8b9a7624b0d95d300ddae034ad0614 中挑選）（CVE-2026-63854）

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

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

  - block：避免在使用者空間掛載 bdev 虛擬檔案系統 bdev 虛擬檔案系統是一個內部核心檔案系統，使用者空間不應與之干涉。取消註冊，讓使用者空間甚至無法嘗試掛載它。這修正了嘗試存取檔案時發生的錯誤 [1]，因為系統呼叫 move_mount（） 使用在 inode_operations 結構中宣告的指標，對於 bdev 虛擬檔案系統來說，這些指標始終等於 0。'inode->i_op = &empty_iops;' [1] 錯誤：核心 NULL 指標解除參照，位址：00000000000000000 #PF：核心模式下的監控程式指令擷取 #PF：error_code（0x0010） - 不存在頁面 PGD 23380067 P4D 23380067 PUD 23381067 PMD 0 哎呀：0010 [#1] 搶佔 SMP KASAN NOPTI CPU：2 PID：17125 通訊：syz-executor.0 未受污染 6.1.155-syzkaller-00350-g84221fde2681 #0 硬體名稱：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS 1.12.0-1 04/01/2014 RIP： 0010：0x0 呼叫追蹤： <TASK> lookup_open.isra.0+0x700/0x1180 fs/namei.c：3460 open_last_lookups fs/namei.c：3550 [內嵌] path_openat+0x953/0x2700 fs/namei.c：3780 do_filp_open+0x1c5/0x410 fs/namei.c：3810 do_sys_openat2+0x171/0x4d0 fs/open.c：1318 do_sys_open fs/open.c：1334 [內嵌] __do_sys_openatfs/open.c：1350 [內嵌] __se_sys_openat fs/open.c：1345 [內嵌] __x64_sys_openat+0x13c/0x1f0 fs/open.c：1345 do_syscall_x64 arch/x86/entry/common.c：51 [內嵌] do_syscall_64+0x35/0x80 arch/x86/entry/common.c：81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 由 Linux 驗證中心 （linuxtesting.org） 使用 Syzkaller 找到。（CVE-2026-63810）

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

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

  - media：i2c：ov8856：在 ov8856_init_controls（） 中出錯時釋放控制處理常式 如果新增控制項失敗，則不會釋放控制項處理常式，請新增錯誤結束標籤，並將現有的錯誤傳回轉換為使用它。
    (CVE-2026-53379)

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

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

  - KEYS：修正 keyctl_pkey_params_get_2（） 中的溢位：內部輸出緩衝區的長度計算不正確，當提供的緩衝區太小時，可能會導致溢位。以密碼編譯基本類型最大長度的大小配置內部輸出，而不是呼叫端提供的大小，以修正錯誤。（CVE-2026-63824）

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

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

  - f2fs：在不可部分完成寫入期間使用原始 inode 讀取 COW 資料 更新不可部分完成寫入檔案時，f2fs_write_begin（） 可能會從 COW inode 讀回先前寫入的資料：
    prepare_atomic_write_begin（） 在 COW inode 中找到區塊並設定use_cow，然後使用 COW inode 建立讀取的 bio：f2fs_submit_page_read（use_cow ？F2FS_I（inode）->cow_inode：inode 等）;f2fs_grab_read_bio（） 決定是否透過 fscrypt_inode_uses_fs_layer_crypto（） 根據該 inode 為 bio 排程 fs 層解密 （STEP_DECRYPT）。但是，正在填充的對開本屬於原始 inode （folio->mapping->host == inode），並且儲存在 COW 區塊中的資料是使用原始 inode 的上下文（而不是 COW inode 的上下文）加密（或保留為純文字）的 -- 請參閱 f2fs_encrypt_one_page（），它鍵關閉 fio->page->mapping->host。fscrypt_decrypt_pagecache_blocks（） 同樣在 folio->mapping->host 上運作。COW inode 會在父目錄中建立為 tmpfile，並從該目錄繼承其加密原則。使用 test_dummy_encryption，新建立的 COW inode 會取得虛擬原則並加密，而預先存在的一般檔案 （在套用原則之前建立），例如
    已存在於磁碟映像中 -- 保持未加密狀態。然後，讀取路徑會根據加密的 COW inode 設定 STEP_DECRYPT，並在主機 （未加密的原始 inode） 具有 NULL ->i_crypt_info 的對開本上呼叫 fscrypt_decrypt_pagecache_blocks（），對其進行解除參照： 哎呀：一般保護錯誤，可能是非規範位址 ... KASAN：範圍 [0x0000000000000008-0x000000000000000f] 中的 null-ptr-deref] RIP：0010：fscrypt_decrypt_pagecache_blocks+0xa0/0x310 工作佇列：
    f2fs_post_read_wq f2fs_post_read_work 呼叫追蹤：fscrypt_decrypt_bio+0x1eb/0x340 f2fs_post_read_work+0xba/0x140 process_one_work+0x91c/0x1a40 worker_thread+0x677/0xe90 kthread+0x2bc/0x3a0 只需要 COW inode 來定位磁碟上的區塊，並且該區塊位址已經被 prepare_atomic_write_begin（） 透過 __find_data_block（cow_inode） 解析為@blkaddr， ...);然後f2fs_submit_page_read（） 直接從該實體@blkaddr中讀取，因此 inode 引數僅選擇讀取後加密上下文，而不是獲取哪個區塊。因此，使用 @inode 讀取會傳回相同的 （最新、尚未提交的） COW 資料，同時使 fs 層解密決策和內嵌加密路徑都使用正確的 （原始 inode 的） 金鑰。讀取站點不再使用 COW inode 後，use_cow旗標就沒有剩餘的消費者;將其從 f2fs_write_begin（） 和 prepare_atomic_write_begin（） 中刪除。（CVE-2026-63811）

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

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

  - NFSv4/flexfiles：拒絕零檔案控點版本計數 ff_layout_alloc_lseg（） 會解碼 flexfiles 版面配置內文中的檔案控點版本陣列計數。該值用作 kzalloc_objs（） 的計數，目前程式碼僅拒絕 NULL。零計數會產生ZERO_SIZE_PTR，即使後面的 flexfile 路徑假設至少存在一個檔案控點版本，也可以儲存在 dss_info->fh_versions 中。在分配之前拒絕 fh_count == 0，以符合 flexfiles GETDEVICEINFO 剖析器中現有的零version_count驗證。以格式錯誤的 flexfile 配置命中狀態執行的 QEMU/KASAN： KASAN： null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP：
    0010：ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 核心錯誤 - 未同步：致命異常 修補的核心拒絕格式錯誤的配置，沒有 KASAN/oops/panic，並且有效的 fh_count=1 迴歸仍會乾淨地開啟、讀取和卸載。（CVE-2026-53392）

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

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

  - drm/amdgpu/vcn：設定 VCN v2.0 enc/dec 環的no_user_fence VCN 編碼器和解碼器環不支援 64 位元使用者柵欄寫入，拒絕具有使用者柵欄的 CS 提交。（從提交 e2b5499fca55f1a32960a311bbb62e35891eaf73 中挑選）（CVE-2026-63856）

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

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

  - f2fs：修正對 fs/f2fs/file.c：845 的 f2fs_get_node_folio_ra（） 核心錯誤進行健全性檢查！哎呀：無效的操作碼：0000 [#1] SMP KASAN NOPTI CPU：0 UID：0 PID：5336 通訊：syz.0.0 未受污染的 syzkaller #0 PREEMPT（完整） 硬體名稱：QEMU 標準電腦 （Q35 + ICH9， 2009）、BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP：0010：f2fs_do_truncate_blocks+0x1115/0x1140 fs/f2fs/file.c：845 代碼：fc fc 90 0f 0b e8 8b 9d 9a fd 90 0f 0b e8 83 9d 9a fd 48 89 df 48 c7 c6 60 d1 1a 8c e8 54 f1FC FC 90 0f 0b e8 6c 9d 9a fd 90 <0f> 0b e8 64 9d 9a fd 90 0f 0b 90 e9 93 fd ff ff e8 56 9d 9a fd 90 RSP：0018：ffffc9000e4474c0 EFLAGS：00010283 RAX：
    ffffffff842b1d34 RBX：0000000000000003 RCX：0000000000100000 RDX：ffffc9000f03a000 RSI：0000000000035503 RDI：0000000000035504 RBP：ffffc9000e447608 R08：ffff8880123b0000 R09：0000000000000002 R10：
    00000000fffffffffe R11： 0000000000000002 R12： 0000000000000001 R13： 0000000000000000 R14： 1ffff92001c88ea0 R15： 00000000ffff039c FS： 00007f7e02ee36c0（0000） GS：ffff88808c887000（0000） knlGS：000000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：00007ff0305c4000 CR3：0000000012d4c000 CR4：0000000000352ef0 呼叫追蹤： <TASK> f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c：882 f2fs_truncate+0x471/0x7c0 fs/f2fs/file.c：940 f2fs_evict_inode+0xa3f/0x1ac0 fs/f2fs/inode c：907 evict+0x61e/0xb10 fs/inode.c：841 f2fs_fill_super+0x5f43/0x78f0 fs/f2fs/super.c：5224 get_tree_bdev_flags+0x431/0x4f0 fs/super.c：1694 vfs_get_tree+0x92/0x2a0 fs/super.c：1754 fc_mount fs/namespace.c：1193 [內嵌] do_new_mount_fc fs/namespace.c：3758 [內嵌] do_new_mount+0x341/0xd30 fs/namespace.c：3834 do_mount fs/namespace.c：4167 [內嵌] __do_sys_mount fs/namespace.c：4383 [內嵌] __se_sys_mount+0x31d/0x420 fs/namespace.c：4360 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 計數 = ADDRS_PER_PAGE（dn.node_folio， inode）;計數 -= dn.ofs_in_node;f2fs_bug_on（sbi，計數< 0）;模糊測試將在 f2fs 中觸發bug_on以上。根本原因應該是：在損毀的 inode 中，有一個直接節點的頁腳有相同的 ino 和 nid，所以在 f2fs_do_truncate_blocks（） 中，f2fs_get_dnode_of_data（） 找到這樣的 dnode 後： 1） ADDRS_PER_PAGE（dn.node_folio， inode） 將傳回 923 2） 一旦 dn.ofs_in_node 指向 addr[923， 1017]那麼就會觸發系統錯誤。讓我們介紹NODE_TYPE_NON_IXNODE來指示當前節點不應是 inode 或 xattr 節點，然後在以下路徑中使用它來檢測 inode 映射表中不一致的節點鏈： - f2fs_do_truncate_blocks - f2fs_get_dnode_of_data - f2fs_get_node_folio_ra - __get_node_folio - f2fs_sanity_check_node_footer - case NODE_TYPE_NON_IXNODE ->檢查它是否是 inode|xnode （CVE-2026-63819）

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

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

  - f2fs：驗證 f2fs_acl_from_disk（） 中的 ACL 項目大小 f2fs_acl_count（） 只會驗證彙總 ACL xattr 長度。格式錯誤的 ACL 仍可將 ACL_USER 或 ACL_GROUP 放在僅包含 struct f2fs_acl_entry_short 位元組的插槽中，然後 f2fs_acl_from_disk（） 在驗證完整項目是否適合之前讀取 entry->e_id。在閱讀e_tag和e_perm之前要求一個簡短的條目，在閱讀ACL_USER和ACL_GROUP的e_id之前要求一個完整的條目。從這些新的截斷項目檢查中傳回 -EFSCORRUPTED，同時保持先前存在的 -EINVAL 路徑不變。驗證重現了此核心報告： __f2fs_get_acl+0x6fb/0x7e0 中的 KASAN slab-out-of-bounds RIP： 0033：0x7f4b835ea7aa 有錯誤的位址屬於 ffff888114589960 的物件，該物件屬於大小為 8 的快取 kmalloc-8 有錯誤的位址位於已分配的 8 位元組區域右側的 0 位元組 [ffff888114589960， ffff888114589968） 大小 4 的讀取 呼叫追蹤：
    dump_stack_lvl+0x66/0xa0 （？：？） print_report+0xce/0x630 （？：？） __f2fs_get_acl+0x6fb/0x7e0 （fs/f2fs/acl.c：169） srso_alias_return_thunk+0x5/0xfbef5 （？：？） __virt_addr_valid+0x224/0x430 （？：？） kasan_report+0xe0/0x110 （？：？） __f2fs_get_acl+0x5/0x7e0 （fs/f2fs/acl.c：169） __get_acl+0x281/0x380 （？：？） vfs_get_acl+0x10b/0x190 （？：？） do_get_acl+0x2a/0x410 （？：?)do_get_acl+0x9/0x410 （？：？） do_getxattr+0xe8/0x260 （？：？） filename_getxattr+0xd1/0x140 （？：？） do_getname+0x2d/0x2d0 （？：？） path_getxattrat+0x16c/0x200 （？：？） lock_release+0xc8/0x290 （？：？） cgroup_update_frozen+0x9d/0x320 （？：？） lockdep_hardirqs_on_prepare+0xea/0x1a0 （？：？） trace_hardirqs_on+0x1a/0x170 （？：？）
    _raw_spin_unlock_irq+0x28/0x50 （？：？） do_syscall_64+0x115/0x6a0 （arch/x86/entry/syscall_64.c：87） entry_SYSCALL_64_after_hwframe+0x77/0x7f （？：？）（CVE-2026-63814）

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

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

  - serial： 8250_dw：如果 clk_notifier_register（） 失敗，則取消註冊 8250 連接埠 dw8250_probe（） 透過 serial8250_register_8250_port（） 註冊 8250 連接埠，然後，如果裝置有時鐘，則註冊時鐘通知程式。
    如果 clk_notifier_register（） 失敗，探測會傳回錯誤，但會保留 8250 連接埠註冊。相符的 serial8250_unregister_port（） 位於 dw8250_remove（） 中，當探查失敗時不會呼叫該 （），因此埠插槽會一直被佔用，直到裝置重新反彈或系統重新啟動為止。devm 配置的驅動程式資料會釋放，而連接埠仍會參考它 （透過已儲存的private_data和 serial_in/serial_out 回呼），因此在重新綁定之前對該埠插槽的任何存取都是釋放後使用的危險。取消註冊 clk_notifier_register（） 錯誤路徑上的連接埠。（CVE-2026-53384）

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

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

  - drm/amdgpu/jpeg：設定 JPEG v2.0 環的no_user_fence JPEG 環不支援 64 位元使用者圍欄寫入，拒絕帶有使用者圍欄的 CS 提交。（從提交 96179da0c6b059eb31706a0abe8dd6381c533143 中挑選）（CVE-2026-63848）

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

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

  - drm/amdgpu/jpeg：設定 JPEG v4.0 環的no_user_fence JPEG 環不支援 64 位元使用者圍欄寫入，拒絕帶有使用者圍欄的 CS 提交。（從提交 8d0cac9478a3f046279c657d6a2545de49ae675a 中挑選）（CVE-2026-63845）

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

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

  - drm/amdgpu/vcn：設定 VCN v4.0 ENC 環的no_user_fence VCN 編碼器和解碼器環不支援 64 位元使用者柵欄寫入，拒絕具有使用者柵欄的 CS 提交。（從提交 fd852c048b46f9825e904a4f3f4538fe9d8827d9 中挑選）（CVE-2026-63853）

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

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

  - apparmor：調解 TCP 快速開啟 sendmsg sendmsg（）/sendto（） 的隱含連接，其中 MSG_FASTOPEN 是 connect（2） 和 write（2） 的組合：它在 SYN 中開啟連線。apparmor_socket_sendmsg（） 只檢查AA_MAY_SEND，因此授予發送但拒絕連接的設定檔允許受限任務開啟 connect（2） 會拒絕的出站 TCP/MPTCP 連線， 繞過 Connect 調解。設定MSG_FASTOPEN並提供目的地時，調解隱含連線。將其新增至 apparmor_socket_sendmsg（） （不是 recvmsg 也使用的共用 aa_sock_msg_perm（） 協助程式）並直接呼叫 aa_sk_perm（），鏡像 selinux 和 tomoyo 修正。sk_is_tcp（） 未涵蓋 MPTCP 快速開啟，因此 SOCK_STREAM/IPPROTO_MPTCP 臂是明確的。（CVE-2026-63828）

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

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

  - f2fs： atomic：修正 f2fs_inode_info.atomic_inode 上的 UAF 問題 - ioctl（F2FS_IOC_GARBAGE_COLLECT_RANGE） - shrink - f2fs_gc - gc_data_segment - ra_data_block（cow_inode） - mapping = F2FS_I（inode）->atomic_inode->i_mapping ： f2fs_is_cow_file（cow_inode） 為 true - f2fs_evict_inode（atomic_inode） - clear_inode_flag（fi->cow_inode， FI_COW_FILE） - F2FS_I（fi->cow_inode）->atomic_inode = NULL ... - truncate_inode_pages_final（atomic_inode） - f2fs_grab_cache_folio（mapping） ：在 atomic_inode->mapping 中建立對開本 - clear_inode（atomic_inode） - BUG_ON（atomic_inode->i_data.nrpages） 在垃圾回收期間使用其映射欄位之前，我們需要先在 fi->atomic_inode 上添加引用，否則會導致 UAF 問題。（CVE-2026-63816）

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

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

  - NFSD：修正解碼錯誤清除 nfsd4_decode_secinfo_no_name（） 目前在解碼sin_style後初始化sin_exp SECINFO_NO_NAME。如果 XDR 資料流被截斷，解碼器會在初始化sin_exp之前傳回nfserr_bad_xdr。由於提交 3fdc54646234 （NFSD：減少需要清除的結構nfsd4_compoundargs數量），因此不會在RPC呼叫之間清除內嵌 iops 陣列。因此，失敗的SECINFO_NO_NAME解碼可能會讓sin_exp保留先前作業中過時的聯集內容。
    錯誤回應路徑仍會叫用 nfsd4_secinfo_no_name_release（），其會在非 NULL sin_exp上呼叫 exp_put（）。在第一個可失敗的解碼步驟之前初始化sin_exp，符合 nfsd4_decode_secinfo（） 。
    (CVE-2026-53398)

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

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

  - wifi：ath11k：修正解除綁定時的警告 如果在某些與韌體相關的初始化過程中發生錯誤，則會釋放緩衝區 dp->tx_ring[i].tx_status。但是，當裝置解除綁定 （ath11k_pci） 時，它會再次釋放，我們會得到： 警告：CPU：0 PID：6231 在 mm/slub.c：4368 free_large_kmalloc+0x57/0x90 呼叫追蹤：free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... 此問題一律可從 VM 重現，因為 MSI 定址初始化失敗。為了解決此問題，只需在釋放後將緩衝區設定為 NULL 即可避免雙重釋放。（CVE-2026-63822）

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

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

  - f2fs：非內嵌 xattr inode 的綁定i_inline_xattr_size 啟用flexible_inline_xattr功能後，do_read_inode（） 會無條件載入磁碟i_inline_xattr_size：if （f2fs_sb_has_flexible_inline_xattr（sbi）） fi->i_inline_xattr_size = le16_to_cpu（ri->i_inline_xattr_size）;
    但 sanity_check_inode（） 僅在 inode 也設定了 FI_INLINE_XATTR 旗標時才對其進行範圍檢查。因此，如果 inode 攜帶內嵌 dentry 或內嵌資料，但不承載 FI_INLINE_XATTR （內嵌目錄的正常配置），則可從特製的映像檔中保留完全由攻擊者控制的i_inline_xattr_size。
    get_inline_xattr_addrs（） 傳回該值，沒有旗標門控，因此它會饋送 inode 幾何圖形：
    MAX_INLINE_DATA（） = 4 * （CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1） NR_INLINE_DENTRY（） = MAX_INLINE_DATA（） * BITS_PER_BYTE / （...） addrs_per_page（） = CUR_ADDRS_PER_INODE - i_inline_xattr_size 較大的i_inline_xattr_size會驅動 MAX_INLINE_DATA（） 和 NR_INLINE_DENTRY（） 為負值，因此 make_dentry_ptr_inline（） 將 d->max （int） 設定為負值。然後，內聯目錄遍歷將無符號長bit_pos與負 d->max 進行比較，後者被提升為一個巨大的無符號邊界，並讀取到遠遠超出內嵌區域：while （bit_pos < d->max） /* fs/f2fs/dir.c */ ...test_bit_le（bit_pos， d->點陣圖） / d->dentry[bit_pos] ... 掛載特製的映像並讀取此類目錄會觸發 f2fs_fill_dentries（） 中的越界讀取;同樣的反向溢位也會損壞常規檔案的ADDRS_PER_INODE。每當啟用 flexible_inline_xattr 功能時（即每當值從磁碟載入並消耗時），針對 MAX_INLINE_XATTR_SIZE 驗證i_inline_xattr_size，並在實際攜帶內嵌 xattr 的 inode 上保持下限MIN_INLINE_XATTR_SIZE界，因此仍接受具有 i_inline_xattr_size == 0 的合法 inode。（CVE-2026-63815）

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

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

  - irqchip/imgpdc：修正資源洩漏，在移除時新增缺少的鏈結處理常式清理 驅動程式在探測期間使用 irq_alloc_domain_generic_chips（） 配置網域通用晶片，並使用 irq_set_chained_handler_and_data（） 設定鏈結處理常式。不過，在移除驅動程式時，不會釋放泛型晶片，也不會移除鏈結處理常式。通用晶片仍保留在全域gc_list上，稍後可能會在移除驅動程式之後，透過通用中斷晶片暫停、繼續或關閉回呼來存取，這可能會導致釋放後使用和核心損毀。安裝在周邊裝置和系統喚醒中斷探測中的鏈結處理常式也會懸置，這可能會導致虛假中斷存取釋放的記憶體。透過以下方式解決這些問題： - 在 domain->flags 中設定IRQ_DOMAIN_FLAG_DESTROY_GC旗標，以便在呼叫 irq_domain_remove（） 時，核心程式碼會自動移除通用晶片
    - 清除 pdc_intc_remove（） 中所有具有 NULL 的鏈結處理常式 （CVE-2026-63798）

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

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

  - wifi：MT76：在 mt76_sta_add 中新增 wcid 發佈簽mt7925_mac_sta_add，因此在mt76_sta_add中新增發佈簽入以避免重新初始化 wcid->poll_list。使用 mt7925 和 7.1-rc4 時發現 dev->sta_poll_list 損毀。根據損毀資訊，prev->next 已變更為自身。
    wlan0：中斷與 AP 90：fb：5d：94：8b：e3 的連線，以進行對 90：fb：5d：94：8b：e2 的新驗證 wlan0：使用 90：fb：5d：94：8b：e2 進行驗證 （本機位址=84：9e：56：9c：7e：6b） wlan0：將驗證傳送至 90：fb：5d：94：8b：e2 （嘗試 1/3） slab kmalloc-8k 啟動 ffff8c80958a6000 指標位移 4160 大小 8192 list_add損毀。prev->next 應該是下一個 （ffff8c808a7488f8），但原來是 ffff8c80958a7040。（prev=ffff8c80958a7040）mt76_wcid_add_poll+0x95/0xd0 [mt76] mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common] mt7925_rx_check+0xa7/0xc0 [mt7925_common] mt76_dma_rx_poll+0x50d/0x790 [mt76] mt792x_poll_rx+0x52/0xe0 [mt792x_lib] （CVE-2026-63832）

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

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

  - NFSD：在 setlease 失敗時釋放配置 STID nfs4_alloc_stid（） 會透過 cl_lock 下的 idr_alloc_cyclic（） 將新的 STID 發佈到 cl->cl_stateids，然後再返回 nfsd4_alloc_layout_stateid（）。
    當 nfsd4_layout_setlease（） 失敗時，錯誤路徑會直接使用 kmem_cache_free（） 釋放配置 stateid，而不呼叫 idr_remove（），讓 IDR 插槽指向釋放的 slab 記憶體。
    任何後續的 IDR 遍歷程式 （states_show，用戶端拆卸） 都會取消參照懸置指標。IDR 發佈的 stid 的正確拆卸是 nfs4_put_stid（），它會移除 cl_lock 下的 IDR 插槽，分派 sc_free （nfsd4_free_layout_stateid） 以透過 nfsd4_close_layout（） 釋放 ls->ls_file，並將 nfs4_file 參照放在其尾部。第二個問題阻礙了該開關：nfsd4_free_layout_stateid（） 在 ls_lock 下透過 delayed_work_pending（） 無條件地檢查 ls->ls_fence_work，但 INIT_DELAYED_WORK（&ls->ls_fence_work， ...） 目前僅在 setlease 呼叫之後執行。在 setlease-failure 路徑上，析構函式會觸及未初始化的delayed_work。nfsd4_alloc_layout_stateid（） nfs4_alloc_stid（） /* cl_lock下的idr_alloc_cyclic */ nfsd4_layout_setlease（） /* 失敗 */ nfs4_put_stid（） nfsd4_free_layout_stateid（） delayed_work_pending（&ls->ls_fence_work） /* 需要 INIT */ nfsd4_close_layout（） /* nfsd_file_put（ls->ls_file） */ put_nfs4_file（） 透過將 ls_fenced / ls_fence_delay / INIT_DELAYED_WORK初始化提升到 nfsd4_layout_setlease（） 呼叫上方來修復， 並將手動nfsd_file_put + put_nfs4_file + kmem_cache_free清理替換為單一 nfs4_put_stid （STP）。（CVE-2026-53399）

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

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

  - drm/msm：一律復原 GPU 以前，如果沒有更多工作要做，復原背景工作角色不會觸發復原，而是依賴 GPU 進入睡眠狀態，然後在提交更多工作時繼續。Recover_worker會先遞增懸掛環的圍欄，因此，如果只有一項工作提交給環並且導致懸置，則該作業將提前退出。無法保證 GPU 會在提交更多工作之前暫停並繼續，如果 GPU 處於懸置狀態，它會保持該狀態，並可能再次觸發逾時。只需停止檢查並始終恢復 gpu。拼湊：
    https://patchwork.freedesktop.org/patch/704066/ (CVE-2026-53377)

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

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

  - mac802154：llsec：在就地加密 llsec_do_encrypt_unauth（）、llsec_do_encrypt_auth（）、llsec_do_decrypt_unauth（） 和 llsec_do_decrypt_auth（） 之前新增 skb_cow_data（），都會對 SKB 資料執行就地密碼編譯轉換。他們建立一個散點表，其中 sg_init_one（） 指向 skb 的線性資料區域，然後將與 src 和 dst 相同的散點表傳遞給加密 API（例如
    crypto_skcipher_encrypt/decrypt， crypto_aead_encrypt/decrypt）。在 RX 路徑上，
    __ieee802154_rx_handle_packet（） 會複製收到的 skb，然後透過 ieee802154_subif_frame（） 將其交給每個訂閱者。複製的 skb 透過參照計數共用相同的基礎資料緩衝區。
    當 llsec_do_decrypt（） 隨後就地修改此共用緩衝區時，它會損毀其他複製 （可能屬於其他通訊端或子系統） 仍參照的資料。在 TX 路徑上，當 skb 的頭部被複製時，可能會發生類似的資料共用 （skb_cloned（） 傳回 true）。修正方法是在執行任何就地加密作業之前呼叫 skb_cow_data（）。skb_cow_data（） 確保 skb 的資料區域不被共享：如果 skb 頭被克隆或資料跨越多個片段，它會將資料複製到可以就地安全修改的私有緩衝區中。這與以下人員使用的模式相同： - ESP （net/ipv4/esp4.c， net/ipv6/esp6.c） - MACsec （drivers/net/macsec.c） - WireGuard （drivers/net/wireguard/receive.c） - TIPC （net/tipc/crypto.c） 如果沒有此防護，共用 skb 資料上的就地加密會導致： - 其他 skb 複製的無訊息資料損毀 - 當加密 API 散佈遍歷寫入已由另一個複製的 kfree_skb（） 釋放的頁面時，釋放後使用 - 核心在並行 802.15.4 下當機啟用安全性的流量 （KASAN/KMSAN 報告釋放後 slab-use） 使用自動化來源分析在 0 秒 （https://0sec.ai） 之前找到。（CVE-2026-63831）

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

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

  - AppArmor：修正 Rawdata 重複資料刪除迴圈中的釋放後使用 aa_replace_profiles（） 遍歷 ns->rawdata_list 以針對已附加到現有設定檔的項目刪除傳入的原則 blob。根據結構 aa_loaddata 上的 kernel-doc，清單成員資格不保留參照：設定檔保留 pcount，當最後一個 pcount 刪除時，do_ploaddata_rmfs（） 會排入佇列，該工作佇列會接受 ns->lock 並移除項目。
    在捨棄最後一個 pcount 和執行工作佇列之間，清單上會保留 pcount == 0 的項目。
    aa_get_profile_loaddata（） 是 pcount 上的無條件 kref_get（），因此當重複資料刪除迴圈命中此類項目時，refcount 強化報告refcount_t：0 上的加法;釋放後使用。在 aa_replace_profiles（） 中，中毒計數器接著會在後續使用相同載入資料時觸發飽和和下溢警告。在提交 a0b7091c4de4 之前 （AppArmor：修正原始資料解除參照上的爭用），重複資料刪除路徑在單一計數器上使用了 get_unless_zero 樣式的協助程式，因此現有的 if （tmp） 防護是有意義的。
    拆分引用計數重構引入了具有簡單 kref_get（） 語義的 aa_get_profile_loaddata（），守衛悄悄地變成了無操作。引入 aa_get_profile_loaddata_not0（），以配合現有的
    _not0 aa_get_profile_not0（） 使用的約定，並將其用於rawdata_list重複資料刪除查詢，以便跳過即將消亡的項目。在 x86_64 上重現 v7.1-rc5 的 QEMU+KVM 運行 Ubuntu 24.04 + stress-ng 0.17.06： stress-ng --apparmor 1 --klog-check --timeout 60s 如果沒有此修補程式，三個refcount_t警告會在幾秒鐘內觸發。有了它，同樣的 60 秒運行是乾淨的。覆蓋範圍僅為煙霧測試;任何有自行車的人都歡迎用CONFIG_KASAN、CONFIG_KCSAN和CONFIG_PROVE_LOCKING浸泡更長時間。（CVE-2026-63827）

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

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

  - netfilter： nf_tables：新增掛鉤事務以刪除裝置 還原指示掛鉤即將消失的標誌，即。NFT_HOOK_REMOVE，但新增一個交易物件來追蹤鉤子的刪除，而無需在準備階段更改基鏈/流程表hook_list。將鉤子從基鏈/流程表hook_list移動到事務hook_list的現有方法破壞了此 RCU 保護清單的網路連結轉儲路徑讀取器。應該可以使用nft_trans_hook數組來存儲已刪除的鉤子以壓縮表示，但我不希望有很多鉤子對象，特別是現在對設備的通配符支持已經到位。請注意，nft_trans_chain_hooks（） 清單包含 DELCHAIN 和 DELFLOWTABLE 命令的結構nft_trans_hook物件清單，而此清單儲存 NEWCHAIN 和 NEWFLOWTABLE 的結構nft_hook物件。請注意，可以更新新命令以使用nft_trans_hook保持一致性。此修補程式也會調整事件通知路徑，以處理勾點交易清單。（CVE-2026-63858）

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

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

  - 提示：修正 tipc_aead_decrypt_done tipc_aead_decrypt（） 中的 slab-use-after-free Read 直接從 tipc_bearer_hold（b） 到 crypto_aead_decrypt（req），而不對 netns 進行參照，這與加密路徑不同。當 crypto_aead_decrypt（） 以非同步方式卸載時 （例如，SIMD aead 包裝函式排入 cryptd），cryptd 工作程式稍後會執行 tipc_aead_decrypt_done（）。如果持有者的 netns 在此期間被拆除，則 cleanup_net（） -> tipc_exit_net（） -> tipc_crypto_stop（） 釋放 per-netns tipc_crypto，然後完成讀取它：tipc_aead_decrypt_done（） 解除參照 aead->crypto->stats 和 aead->crypto->net，tipc_crypto_rcv_complete（） 取消參照 aead->crypto->aead[] 和節點表 -- 讀取釋放的記憶體。解碼的 KASAN splat （v7.1-rc7， CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO）： 錯誤：
    KASAN：tipc_aead_decrypt_done中的 slab-use-after-free （net/tipc/crypto.c：999） 在 addr ffff8881056258a8 由任務 kworker/u16：2/51 讀取大小 8 工作佇列：events_unbound 呼叫追蹤：tipc_aead_decrypt_done （net/tipc/crypto.c：999） process_one_work （kernel/workqueue.c：3314） worker_thread （kernel/workqueue.c：3397 kernel/workqueue.c：3478） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：158） ret_from_fork_asm （arch/x86/entry/entry_64.S：245） 由作業 169：__kasan_kmalloc （mm/kasan/common.c：398 mm/kasan/common.c：415） tipc_crypto_start （net/tipc/crypto.c：1502） tipc_init_net （net/tipc/core.c：72） ops_init （net/core/net_namespace.c：137） setup_net （net/core/net_namespace.c：446） copy_net_ns （net/core/net_namespace.c：579） create_new_namespaces （kernel/nsproxy.c：132） __x64_sys_unshare （kernel/fork.c：3316） do_syscall_64 （arch/x86/entry/syscall_64.c：63） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） 由任務 8 釋放： kfree （mm/slub.c：6566） tipc_exit_net （net/tipc/core.c：119） cleanup_net （net/core/net_namespace.c：704） process_one_work （kernel/workqueue.c：3314） kthread （kernel/kthread.c：436） 這是為加密端修正的提交 e279024617134 （net/tipc：修正 tipc_aead_encrypt_done 中的 slab-use-after-free Read ） 的同一類錯誤。加密路徑在 crypto_aead_encrypt（） 之前採用 maybe_get_net（aead->crypto->net），並在同步傳回路徑和 tipc_aead_encrypt_done（） 中與 put_net（） 一起將其丟棄;-EINPROGRESS/-EBUSY 傳回會保留非同步回呼以釋放的參照。解密路徑沒有等效的防護。在解密路徑上鏡像加密端修正：在 crypto_aead_decrypt（） 之前取得網路參照 （如果無法取得，則以 -ENODEV 失敗，並放置相符的持有人），將其保留在 -EINPROGRESS/-EBUSY 非同步傳回中，並在同步成功/錯誤傳回時和 tipc_aead_decrypt_done（） 結尾使用 put_net（） 將其刪除。在 v7.1-rc7 的 KASAN 下重現：具有叢集金鑰的 UDP 承載被來自未知對等體的特製加密框架淹沒（驅動叢集金鑰解密路徑），而承載的 netns 被反覆拆除。完成必須以非同步方式執行，才能超過tipc_crypto_stop（）;在 x86 上，庫存 AESNI GCM（AES） 現在會同步解密，因此非同步路徑是透過 cryptd 卸載來執行的。tipc_aead_decrypt_done（） 中不受保護的 aead->crypto 解除參照是未修補的上游路徑;tipc_aead_decrypt（） 仍然缺少 maybe_get_net（aead->crypto->net），因此在 crypto_aead_decrypt（） 非同步的任何配置上，完成時間都可能超過釋放時間。由 0sec 自動化安全研究工具 （）https://0sec.ai 找到。（CVE-2026-63801）

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

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

  - drm/amdgpu/vce：防止部分位址修補 如果只有一個 lo/hi 有效，修補可能會導致 FW 中寫入錯誤位址。（CVE-2026-53375）

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

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

  - NFSD：在延遲的回寫錯誤上重設寫入驗證程式 nfsd_vfs_write（） 和 nfsd_commit（） 都會呼叫 filemap_check_wb_err（） 來偵測延遲的回寫錯誤，但當此檢查失敗時，兩者都不會輪替伺服器的寫入驗證程式 （nn->writeverf）。這些函式中的所有其他持久儲存失敗路徑都會在傳回錯誤之前呼叫 commit_reset_write_verifier（）。遺漏的輪替表示在目前驗證程式下保留 UNSTABLE 寫入資料的用戶端將認可、接收未變更的驗證程式，並得出結論，其資料是持久性的，以無訊息的方式捨棄回寫失敗的資料。這違反了 UNSTABLE+COMMIT 持久性合約 （RFC 1813 3.3.7、RFC 8881 18.32）。在兩個 filemap_check_wb_err（） 錯誤站點新增 commit_reset_write_verifier（） 呼叫，以符合相同函式中相鄰錯誤路徑所使用的模式。協助程式已經在內部篩選了 -EAGAIN 和 -ESTALE，因此呼叫是無條件安全的。（CVE-2026-53393）

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

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

  - net：airoha：不要讀取 airoha_dev_xmit（） 中未初始化的片段位址 airoha_dev_xmit（） 中的傳輸迴圈在其最終迭代期間讀取片段位址和長度，當迴圈索引等於 skb_shinfo（skb）->nr_frags 時，此時片段資料被取消初始化。雖然永遠不會使用這些值，但讀取本身是不安全的，可能會觸發頁面錯誤。若要修正此問題，請避免在上次反覆運算時讀取片段。此外，將 skb 指標從第一個到最後一個使用的封包描述元移動，以便 airoha_qdma_tx_napi_poll（） 延遲釋放 skb，直到處理最終描述元為止。（CVE-2026-63857）

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

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

  - drm/amdgpu/jpeg：設定 JPEG v3.0 環的no_user_fence JPEG 環不支援 64 位元使用者圍欄寫入，拒絕帶有使用者圍欄的 CS 提交。（從提交 4d7d774f100efb5089c86a1fb8c5bf47c63fc9ef 中挑選）（CVE-2026-63846）

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

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

  - ocfs2：拒絕過大的群組點陣圖描述元 ocfs2_validate_gd_parent（） 僅針對父配置器的鏈幾何圖形bg_bits邊界。惡意描述元仍可宣告超過實際適合群組描述元區塊的點陣圖位元組的 bg_size/bg_bits 配對，因此稍後的點陣圖掃描和位元更新可能會在bg_bitmap之後執行。針對父配置器類型新增基於 ocfs2_group_bitmap_size（） 的實體上限檢查，並拒絕其bg_size或bg_bits超過該容量的描述元。保留現有的鏈結幾何檢查，讓磁碟上的點陣圖配置和配置器中繼資料都必須同意，才能使用描述元。驗證重現了此核心報告：KASAN 在
    _find_next_bit+0x7f/0xc0 讀取大小 8 呼叫追蹤：dump_stack_lvl+0x66/0xa0 （？：？） print_report+0xd0/0x630 （？：？） _find_next_bit+0x7f/0xc0 （？：？） srso_alias_return_thunk+0x5/0xfbef5 （？：？）
    __virt_addr_valid+0x188/0x2f0 （？：？） kasan_report+0xe4/0x120 （？：？） ocfs2_find_max_contig_free_bits+0x35/0x70 （fs/ocfs2/suballoc.c：1375） ocfs2_block_group_set_bits+0x472/0x4b0 （fs/ocfs2/suballoc.c：1457） ocfs2_cluster_group_search+0x16b/0x440 （fs/ocfs2/suballoc.c：86） ocfs2_bg_discontig_fix_result+0x1ef/0x230 （fs/ocfs2/suballoc.c：1786） ocfs2_search_chain+0x8f8/0x10a0 （fs/ocfs2/suballoc.c：1886） get_page_from_freelist+0x70e/0x2370 （？：?)lock_release+0xc6/0x290 （？：？） do_raw_spin_unlock+0x9a/0x100 （？：？） kasan_unpoison+0x27/0x60 （？：？）
    __bfs+0x147/0x240 （？：？） get_page_from_freelist+0x83d/0x2370 （？：？） ocfs2_claim_suballoc_bits+0x38c/0xe70 （fs/ocfs2/suballoc.c：96） sched_domains_numa_masks_clear+0x70/0xd0 （？：？） check_irq_usage+0xe8/0xb70 （？：？）
    __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c：？）down_write+0xf5/0x180 （？：？） ocfs2_write_begin+0x180/0x240 （fs/ocfs2/suballoc.c：？） __mark_inode_dirty+0x758/0x9a0 （？：？） inode_to_bdi+0x41/0x90 （？：？） balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 （？：？） generic_perform_write+0x252/0x440 （？：？） mnt_put_write_access_file+0x16/0x70 （？：？） file_update_time_flags+0xe4/0x200 （？：？） ocfs2_file_write_iter+0x80a/0x1320 （fs/ocfs2/suballoc.c：?)lock_acquire+0x184/0x2f0 （？：？） ksys_write+0xd2/0x170 （？：？） apparmor_file_permission+0xf5/0x310 （？：？） read_zero+0x8d/0x140 （？：？） lock_is_held_type+0x8f/0x100 （？：？）（CVE-2026-63796）

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

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

  - 藍牙：ISO：使用 iso_pi（sk）->dst、iso_pi（sk）->src 和 iso_pi（sk）->src_type 來修正hci_get_route呼叫 iso_connect_bis（）、iso_listen_bis iso_connect_cis（） 和 iso_conn_big_sync（） 呼叫 hci_get_route（） 中iso_pi欄位的資料爭用，而不按住 lock_sock（）。這些欄位可能會由相同通訊端上的 connect（） 或 setsockopt（） 同時修改，導致 KCSAN 報告資料爭用。
    在呼叫 hci_get_route（） 之前，先對 lock_sock（） 下的必要欄位進行快照，以修正此問題。錯誤：KCSAN：
    來源不明的 memcmp+0x45/0xb0 爭用中的數據爭用，CPU 1 上的任務 333 讀取到 1 位元組的0xffff8880122135cf：memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110
    __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f （CVE-2026-63871）

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

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

  - ntfs：序列化磁碟區標籤存取 使用互斥保護磁碟區>volume_label，並在copy_to_user之前將標籤 snaphost 。這樣可以防止當 FS_IOC_SETFSLABEL 取代 vol->volume_label 並FS_IOC_GETTSLABEL同時讀取它時發生釋放後使用。（CVE-2026-63793）

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

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

  - net： ip_gre：需要在裝置 netns 中CAP_NET_ADMIN以用於 changelink 通道 changelink（） 最多在兩個 netn 上運行，即 dev_net（dev） 和通道連結 netns t->net。一旦裝置在執行要求的 netns 中建立或移動至 netns 以外的 netns，它們就會有所不同。rtnl changelink 路徑僅針對 dev_net（dev） 檢查CAP_NET_ADMIN，因此在 t->net 中具有權限但不在 t-net 中的呼叫者可以重寫位於 t->net 中的隧道。在 net/core/rtnetlink.c 中的 rtnl_get_net_ns_capable（） 旁邊新增 rtnl_dev_link_net_capable（）。它需要在連結 netns 中CAP_NET_ADMIN，當連結 netns 為 dev_net（dev） 時，會略過它，其中 rtnl 路徑已經檢查過它。此系列中的其他修補程式使用相同的協助程式。在剖析任何屬性之前，將 ipgre_changelink（） 和 erspan_changelink（） 放在操作的頂端，因為剖析器會先更新即時通道欄位。ipgre_netlink_parms（） 會在 ip_tunnel_changelink（） 執行之前設定 t->collect_md。提交 8b484efd5cb4 （ip6： vti：在 vti6_siocdevprivate（）.） 中使用 ip6_tnl.net。在 ioctl 路徑上新增了相同的檢查。這增加了RTM_NEWLINK。（CVE-2026-63829）

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

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

  - rpmsg： char：修正探查錯誤路徑上的釋放後使用 rpmsg_chrdev_probe（） 會在呼叫 rpmsg_chrdev_eptdev_add（） 之前，將新配置的 eptdev 儲存在預設端點的 priv 指標中。如果 rpmsg_chrdev_eptdev_add（） 隨後失敗，其錯誤路徑會釋放 eptdev，而預設端點仍可能使用過時的 priv 指標分派回呼。避免透過預設端點發佈 eptdev，直到 rpmsg_chrdev_eptdev_add（） 成功為止。在發佈 priv 指標之前收到的訊息應被 rpmsg_ept_cb（） 忽略。流量控制更新可能會在同一視窗中命中 rpmsg_ept_flow_cb（），因此當 priv 為 NULL 時，使兩個回呼都傳回成功。（CVE-2026-63797）

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

ID	名稱	嚴重性
327909	Linux Distros 未修補弱點：CVE-2026-64160	critical
327908	Linux Distros 未修補弱點：CVE-2026-64109	high
327905	Linux Distros 未修補弱點：CVE-2026-53994	high
327904	Linux Distros 未修補弱點：CVE-2026-64125	critical
327903	Linux Distros 未修補弱點：CVE-2026-64072	high
327902	Linux Distros 未修補弱點：CVE-2026-64115	high
327894	Linux Distros 未修補弱點：CVE-2026-63833	high
327893	Linux Distros 未修補弱點：CVE-2026-63803	high
327892	Linux Distros 未修補弱點：CVE-2026-53402	high
327891	Linux Distros 未修補弱點：CVE-2026-63847	high
327890	Linux Distros 未修補弱點：CVE-2026-63809	high
327889	Linux Distros 未修補弱點：CVE-2026-63808	critical
327888	Linux Distros 未修補弱點：CVE-2026-53374	high
327887	Linux Distros 未修補弱點：CVE-2026-63859	high
327886	Linux Distros 未修補弱點：CVE-2026-53391	high
327885	Linux Distros 未修補弱點：CVE-2026-63854	high
327884	Linux Distros 未修補弱點：CVE-2026-63810	high
327883	Linux Distros 未修補弱點：CVE-2026-53379	medium
327882	Linux Distros 未修補弱點：CVE-2026-63824	high
327881	Linux Distros 未修補弱點：CVE-2026-63811	medium
327880	Linux Distros 未修補弱點：CVE-2026-53392	high
327879	Linux Distros 未修補弱點：CVE-2026-63856	high
327878	Linux Distros 未修補弱點：CVE-2026-63819	high
327877	Linux Distros 未修補弱點：CVE-2026-63814	high
327876	Linux Distros 未修補弱點：CVE-2026-53384	critical
327875	Linux Distros 未修補弱點：CVE-2026-63848	high
327874	Linux Distros 未修補弱點：CVE-2026-63845	high
327873	Linux Distros 未修補弱點：CVE-2026-63853	high
327872	Linux Distros 未修補弱點：CVE-2026-63828	high
327871	Linux Distros 未修補弱點：CVE-2026-63816	high
327870	Linux Distros 未修補弱點：CVE-2026-53398	critical
327869	Linux Distros 未修補弱點：CVE-2026-63822	high
327868	Linux Distros 未修補弱點：CVE-2026-63815	high
327867	Linux Distros 未修補弱點：CVE-2026-63798	medium
327866	Linux Distros 未修補弱點：CVE-2026-63832	high
327865	Linux Distros 未修補弱點：CVE-2026-53399	critical
327864	Linux Distros 未修補弱點：CVE-2026-53377	medium
327863	Linux Distros 未修補弱點：CVE-2026-63831	high
327862	Linux Distros 未修補弱點：CVE-2026-63827	high
327861	Linux Distros 未修補弱點：CVE-2026-63858	high
327860	Linux Distros 未修補弱點：CVE-2026-63801	high
327859	Linux Distros 未修補弱點：CVE-2026-53375	high
327858	Linux Distros 未修補弱點：CVE-2026-53393	high
327857	Linux Distros 未修補弱點：CVE-2026-63857	critical
327856	Linux Distros 未修補弱點：CVE-2026-63846	high
327855	Linux Distros 未修補弱點：CVE-2026-63796	high
327854	Linux Distros 未修補弱點：CVE-2026-63871	medium
327853	Linux Distros 未修補弱點：CVE-2026-63793	high
327852	Linux Distros 未修補弱點：CVE-2026-63829	high
327851	Linux Distros 未修補弱點：CVE-2026-63797	high

偵測

Nessus 的 Misc. 系列

critical

high

high

critical

high

high

high

high

high

high

high

critical

high

high

high

high

high

medium

high

medium

high

high

high

high

critical

high

high

high

high

high

critical

high

high

medium

high

critical

medium

high

high

high

high

high

high

critical

high

high

medium

high

high

high