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

  - serial： zs： 轉換為使用平台裝置 防止在第一個序列埠初始化時發生當機： 主控台：切換到單聲道畫面緩衝裝置 160x64 fb0： tc0 上的 PMAG-AA 訊框緩衝裝置 DECstation Z85C30 序列驅動程式版本 0.10 CPU 0 無法處理虛擬位址 0000002c， epc == 803ab00c， ra == 803aafe0 的核心分頁要求 哎呀[#1]： CPU：0 PID：1 通訊：交換器未受污染 6.4.0-rc3-00031-g84a9582fd203-dirty #57 $ 0 ： 00000000 10012c00 803aaeb0 00000000 $ 4 ： 80e12f60 80e12f50 80e12f58 81000030 $ 8 ： 00000000 805ff37c 00000000 33433538 $12 ： 65732030 00000006 80c2915d 6c616972 $16 ： 800 e12f00 807b7630 000000000 00000000 $20 ： 00000004 00000348 000001a0 807623b8 $24 ： 00000018 00000000 $28 ： 80c24000 80c25d60 8078b148 803aafe0 嗨 ： 000000000 低價 ： 00000000 epc ： 803ab00c serial_base_ctrl_add+0x78/0xf4 RA ： 803aafe0 serial_base_ctrl_add+0x4c/0xf4 狀態：10012c03 核心 EXL IE 原因：00000008 （ExcCode 02） BadVA：0000002c PrId：00000440 （R4400SC） 連結於：進程交換器 （PID： 1， threadinfo=（ptrval）， task=（ptrval）， tls=00000000） 堆疊 ： 80760000 00000cc0 00400044 00400040 803aa02c 80d61ab8 00000000 807b7630 8 0760000 807623b8 807b7628 803aa644 80386998 00000000 80e17780 80220f68 80e17780 80d61ab8 80c17d80 80e17780 80e17780 8063c798 80e17780 80383fa0 00000010 80e17780 00000000 80386998 807a0000000000000 00400040 8038f848 807623b8 80d61ab8 00000004 80e17780 00000000 803a68e4 80c25e2c 803bb884 ... 呼叫追蹤：[<803ab00c>] serial_base_ctrl_add+0x78/0xf4 [<803aa644>] serial_core_register_port+0x174/0x69c [<8077e9ac>] zs_init+0xc8/0xfc [<800404d4>] do_one_initcall+0x40/0x2ac [<8076cecc>] kernel_init_freeable+0x1e4/0x270 [<80605bec>] kernel_init+0x20/0x108 [<800431e8>] ret_from_kernel_thread+0x14/0x1c 代碼：2442aeb0 ae120024 ae0200d0 <8c67002c> 50e00001 8c670000 3c06806e 3c05806e afb30010 ---[ 結束追蹤 00000000000000000000 ]--- （在違規提交時報告） -- 其中指標被取消參照，該指標已派生自 null指向連接埠父裝置的指標。由於沒有裝置可用於舊版探測，而且無論如何都不再是探索裝置的首選方式，因此請將驅動程式切換為使用平台裝置，並將其用作埠的父裝置。據以更新資源處理，並只要求插槽內使用的實際位址範圍，其資源已由一般平台裝置程式碼要求。使用 platform_driver_probe（） 不僅因為 SCC 設備是用焊料固定的，並且不容易去除，而且最重要的是因為相關 TTY 的主要設備編號與 dz 驅動程序使用的相同，並且第一個聲稱它的驅動程序將阻止另一個驅動程序使用它。一個 DZ 設備或一些 SCC 設備將存在於給定的系統中，但絕不會同時存在兩個設備，因此我們希望第一個驅動程序聲明主要設備編號，以實際成功綁定到其設備，而 platform_driver_probe（） 是一種實現這一點的方法。切換到平台設備的一個不幸後果是，我們現在在引導程序中稍後從引導控制台移交控制台。固件控制台處理程序看起來足夠好，可以工作這麼晚，尤其是在啟用中斷的情況下。由於現在只有一種方法可以到達 zs_reset（），因此請在不再需要時移除連接埠初始化標記，並無條件地進行通道重設。
    (CVE-2026-63876)

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

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

  - igc：修正 igc_fpe_xmit_smd_frame（） 中潛在的 skb 洩漏 當 igc_fpe_init_tx_descriptor（） 失敗時，沒有人處理分配的 skb，從而洩露它。[1] 失敗時使用 dev_kfree_skb_any（）。使用以下命令在轉接器上 I226 進行測試，同時在 igc_fpe_init_tx_descriptor（） 中插入錯誤以觸發錯誤路徑。 # ethtool --set-mm $DEV verify-enabled on tx-enabled on pmac-enabled on [1] 未參照的物件0xffff888113c6cdc0 （大小 224）： ...回溯 （crc be3d3fda）：
    kmem_cache_alloc_node_noprof+0x3b1/0x410 __alloc_skb+0xde/0x830 igc_fpe_xmit_smd_frame.isra.0+0xad/0x1b0 igc_fpe_send_mpacket+0x37/0x90 ethtool_mmsv_verify_timer+0x15e/0x300 （CVE-2026-64110）

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

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

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

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

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

  - wifi：rtw88：usb：修正 USB 寫入失敗時的記憶體洩漏 當 rtw_usb_write_port（） 無法提交 USB 要求區塊 （URB） 時 （例如，由於裝置中斷連線或 ENOMEM），永遠不會執行完成回呼。
    目前，驅動程式會忽略 rtw_usb_write_data（） 和 rtw_usb_tx_agg_skb（） 中 rtw_usb_write_port（） 的傳回值。因為這些函式依賴完成回呼來釋放通訊端緩衝區 （skbs） 和事務控制區塊 （txcb），所以提交失敗會導致： 1. rtw_usb_write_data（） 中分配的 skb 記憶體洩漏。2. txcb 結構和 rtw_usb_tx_agg_skb（） 中所有聚合的 skb 的記憶體洩漏。透過檢查 rtw_usb_write_port（） 的傳回值來解決此問題。如果失敗，請明確釋放 rtw_usb_write_data（） 中的 skb，並正確清除 tx_ack_queue 並釋放 rtw_usb_tx_agg_skb（） 中的 txcb。此問題是在裝置中斷連線/重新連線案例和記憶體壓力狀況期間實際發現的。透過驗證修正後繼續正常的 TX 作業而進行測試，而不會發生迴歸。（CVE-2026-63821）

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

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

  - scsi：target：iscsi：綁定的 iscsi_encode_text_output（） 附加到 rsp_buf iscsi_encode_text_output（） 將 key=value\0 記錄串連到 login->rsp_buf，這是一個在 iscsit_alloc_login_setup_buffer（） 中配置的 8192 位元組 kzalloc（MAX_KEY_VALUE_PAIRS） 緩衝區。此函式中的三個 sprintf（） 呼叫網站 （v7.1-rc2 中的第 1398、1411、1424 行） 從不檢查剩餘的緩衝區容量： *length += sprintf（output_buf， %s=%s， er->key， er->value）;*長度 += 1;output_buf = textbuf + *length;iscsi_target_check_login_request（） 處的 8192 位元組上限限制了 *輸入* 登入 PDU 有效負載，但單個 PDU 最多可以承載 2048 個最小的四位元組 a=b\0 對，每個未知鍵通過 iscsi_add_notunderstood_response（） 擴展為 16 位元組的 a=NotUnderstood\0 輸出記錄。2048 * 16 = 32 KiB 的輸出輸入 8 KiB 緩衝區，在 kmalloc-8k slab 中產生 ~24 KiB 堆積溢位。此修正引進靜態 iscsi_encode_text_record（） 協助程式，該協助程式使用 snprintf（） 對剩餘緩衝區進行每次呼叫邊界檢查，並透過 iscsi_encode_text_output（） 執行緒 u32 textbuf_size 參數。iscsi_target_handle_csg_zero（） （PHASE_SECURITY） 和 iscsi_target_handle_csg_one（） （PHASE_OPERATIONAL） 中的兩個呼叫網站都會傳遞MAX_KEY_VALUE_PAIRS。在溢位時，編碼器會記錄條件，呼叫 iscsi_release_extra_responses（） 以刪除佇列記錄，並傳回 -1;現在，兩個呼叫端網站都會在傳回之前透過 iscsit_tx_login_rsp（） 發出ISCSI_STATUS_CLS_INITIATOR_ERR/ISCSI_LOGIN_STATUS_INIT_ERR，因此啟動器會看到明確的登入失敗回應，而不是無訊息連線中斷。（在此修補程式之前，只有PHASE_OPERATIONAL呼叫端執行此動作;PHASE_SECURITY呼叫端會轉換成相同的圖形。（CVE-2026-63887）

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

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

  - fprobe：修正 unregister_fprobe（） 以等待 RCU 寬限期 提交 4346ba1604093 （fprobe：在函數圖追蹤器上重寫 fprobe） 已變更 fprobe 以將結構 fprobe 註冊到 rcu-hlist，但它忘記等待 RCU GP。因此，如果在取消註冊後立即釋放 fprobe，則可能會有釋放後使用。這可能發生在 fprobe 事件和範例模組程式碼上。若要修正此問題，請在 unregister_fprobe（） 中新增 synchronize_rcu（）。請注意，BPF 是可以的，因為 fprobe 用作 bpf_kprobe_multi_link 的一部分。這會在 bpf_kprobe_multi_link_release（） 中取消註冊其 fprobe，並透過從 bpf_link_defer_dealloc_rcu_gp（） RCU 回呼叫用的 bpf_kprobe_multi_link_dealloc（） 解除配置。對於 BPF，這也引入了 unregister_fprobe_async（），它不會等待 RCU 寬限優先。
    (CVE-2026-64075)

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

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

  - net/smc：不要重新初始化 smc_nl_init（）、proto_register（） 和 sock_register（） 之後呼叫的 smc 雜湊表 INIT_HLIST_HEAD（&smc_v*_hashinfo.ht）。這可能會導致 smc_v*_hashinfo.ht 被重設，即使雜湊項目已經存在並且正在使用中，也可能導致清單損毀。移除 smc_init（） 中不必要且危險的 smc_v*_hashinfo.ht 重新初始化;無論如何，它都會隱含地初始化為零。為了清楚起見，在定義中新增HLIST_HEAD_INIT。（CVE-2026-64005）

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

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

  - 跟蹤：避免在截斷時從 hist_field_name（） 傳回 NULL hist_field_name（） 在除完整 VAR_REF/EXPR 情況外的所有位置傳回，其中 snprintf（） 截斷會提前傳回 NULL 並繞過底部 NULL >保護。調用方不期望 NULL：trace_events_hist.c：1758 處的 strcat（expr， hist_field_name（field， 0）） 和 ：4804 處的排序鍵比對迴圈中的 strcmp（） 都會對其進行解參照。system 和 event_name 以 MAX_EVENT_NAME_LEN 為界，但VAR_REF上的欄位名稱是從觸發字串剖析的直方圖變數名稱 kstrdup，且沒有長度上限，因此完整參照中足夠長的 var 名稱可以到達截斷路徑。保留長度檢查，但保留field_name如溢位。（CVE-2026-64028）

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

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

  - 在截至 的 Enquirer 2.4.1中發現一個安全漏洞。受影響的是元件 Public Package API 的函式 Enquirer.set。參數 question.name 的操控會導致物件原型屬性的修改控制不當。攻擊者可在遠端執行此攻擊。該漏洞利用程式已對外公開，可能被用於發動攻擊。該項目很早就通過問題報告得知了這個問題。（CVE-2026-15187）

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

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

  - netfs：如果 fd open O_RDWR，則修正寫入串流停用 在 netfs_perform_write（） 中，執行寫入串流 （在 dirty 但 ！uptodate 對開本中快取已變更資料），以避免讀取將立即被覆寫的資料。但是，在三種情況下，這將被禁用：如果 fd 是開放的O_RDWR，如果 fscache 正在使用中（因為我們需要對 DIO 的塊進行四捨五入）或如果啟用了內容加密（同樣是為了四捨五入的目的）。如果 fd 是開啟的O_RDWR，則停用它背後的想法是，我們需要先排清寫入串流頁面，然後才能讀取資料，特別是透過 mmap。但是如果在頁面上調用 ->read_folio（），netfs 現在會填補空白，因此沒有必要。此外，如果打開單獨的 fd 供讀取，這實際上不起作用。透過移除 O_RDWR 檢查來修正此問題，從而允許串流寫入，即使我們可能會讀取。這導致 generic/522 xfstest 出現許多問題，但這些問題現已修正。（CVE-2026-64158）

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

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

  - IIO：化學：MHZ19B：拒絕過大的序列回覆 mhz19b_receive_buf（） 會將每個 serdev 區塊附加到固定的 MHZ19B_CMD_SIZE 接收緩衝區中，並由 len 推進buf_idx，而不檢查區塊是否適合剩餘空間。因此，在命令路徑驗證回覆之前，大型回呼可能會溢位 st->buf。在每個命令之前重設回覆狀態，並在將過大的序列回覆複製到固定緩衝區之前拒絕它們。偵測到過大的回覆時，請喚醒服務員並報告 -EMSGSIZE，而不是覆寫 st->buf。（CVE-2026-63932）

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

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

  - drm/msm/snapshot：修正未對齊區域的傾印 快照程式碼在內部將資料區段對齊為 16 位元組。這適用於 DPU 程式碼 （其中大部分區域已對齊） ，但無法進行 DSI 資料的快照 （因為 DSI 資料區域會移位 4 個位元組）。透過移除長度對齊方式並準確列印區域中的最後暫存器來修正程式碼。在重構程式碼的同時，也修正了 msm_disp_state_dump_regs（） 中 16 倍記憶體過度配置的問題。拼湊：
    https://patchwork.freedesktop.org/patch/725449/ (CVE-2026-64039)

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

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

  - F2FS：修正大型對開本錯誤上缺少的已讀取生物記錄提交 f2fs_read_data_large_folio（） 可以在多個預讀對開本中保留已讀取生物。如果更新的對開本在其任何區塊新增至簡介之前遇到錯誤，則folio_in_bio為 false，且目前的錯誤路徑會在結束該對開本後立即傳回。
    這可能會使先前作品集累積的履歷未提交。然後，這些對開本永遠不會收到讀取完成，讀者可以在鎖定的對開本上無限期地等待。透過通用輸出路徑路由錯誤，以便在返回之前提交任何擱置的簡歷。一旦發現錯誤，就停止使用更多的預讀作品集，只有在當前作品集實際添加到個人簡介中時才等待並清除它。
    (CVE-2026-63820)

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

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

  - mm/migrate_device：修正 migrate_vma_insert_huge_pmd_page 中的微調鎖定洩漏 當透過 pmd_lock（） 取得 PMD 微調鎖定後 check_stable_address_space（） 失敗時，程式碼會直接跳至中止標籤，繞過 unlock_abort 中的 spin_unlock（） 呼叫。這會導致 PMD 微調鎖定永久保留，進而導致鎖死。將 goto 目標從中止變更為 unlock_abort，以確保一律在此錯誤路徑上釋放微調鎖定。（CVE-2026-64129）

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

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

  - igc：設定 SMD 框架的 tx 緩衝區類型Sashiko 指出，igc_fpe_init_smd_frame（） 初始化 SMD skb 的 igc_tx_buffer 字段，但不設定緩衝區類型：
    https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp 由於重複使用igc_tx_buffer項目，因此可能會保留過時的 XDP 或 XSK 類型，並使 TX 完成使用錯誤的清理路徑。將緩衝區類型設定為 IGC_TX_BUFFER_TYPE_SKB。（CVE-2026-64035）

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

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

  - ipv6：在複製到 cmsg ip6_datagram_recv_specific_ctl（） 組建之前，驗證擴充標頭長度 IPV6_{HOPOPTS，DSTOPTS，RTHDR} cmsgs （及其 IPV6_2292* 舊版對應物），方法是在計算 put_cmsg（） 長度時信任線上 hdrlen 位元組 （ptr[1]）。長度僅在剖析時驗證 （ipv6_parse_hopopts（） 等）。nftables payload-write 運算式可以在剖析之後和 skb 到達 recvmsg 之前重寫 hdrlen;寫入本身是邊界，但 put_cmsg（） 然後從 8 位元組標頭讀取最多 （（HDRLEN+1） << 3） = 2040 位元組。nftables 可從無特權的使用者命名空間存取，因此這是無特權的 slab-out-of-bounds 讀取： 錯誤： KASAN：put_cmsg+0x3ac/0x540 put_cmsg+0x3ac/0x540 udpv6_recvmsg+0xca0/0x1250 sock_recvmsg+0xdf/0x190 ____sys_recvmsg+0x1b1/0x620 中的 slab-out-of-bounds 新增 ipv6_get_exthdr_len（），用於驗證在讀取 hdrlen 欄位之前至少可以存取兩個位元組， 然後根據 skb_tail_pointer （SKB） 檢查計算的長度，失敗時傳回 0。擴充標頭在輸入期間由 pskb_may_pull（） 保留在線性 skb 區域中，因此 skb_tail_pointer（） 是正確的邊界。在所有非 AH 呼叫站點使用 ipv6_get_exthdr_len（）：五個獨立的 cmsg 區塊 （HbH、2292HbH、2292DSTOPTS x2、2292RTHDR） 和擴充標頭遍歷迴圈中的三個標準案例 （DSTOPTS、ROUTING、預設值）。AH 會保留內嵌邊界檢查，因為它的長度公式不同 （（ptr[1]+2）<<2）。遍歷迴圈也會在頂端取得預先讀取邊界檢查，以在任何案例存取 ptr[0] 或 ptr[1] 之前驗證 ptr。當遍歷迴圈偵測到損毀的標頭時，請從函式傳回，而不是繼續處理後續的通訊端選項。（CVE-2026-63920）

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

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

  - ksmbd：修正 smb_check_perm_dacl（） 中的越界讀取 smb_check_perm_dacl（） 中的權限檢查 ACE 遍歷會驗證 ACE 標頭大小，並將sid.num_subauth上限設為 SID_MAX_SUB_AUTHORITIES，但它從不檢查 ace->size 實際上是否足夠大，可以在 compare_sids（） 取消參照之前包含num_subauth子授權單位。CIFS_SID_BASE_SIZE 涵蓋陣列之前但不包括 sub_auth[] 陣列的 SID 標頭，而 offsetof（struct smb_ace， sid） 是 ACE 標頭，因此現有的守衛僅保證 8 位元組的 SID 基礎，即零子授權單位。然後compare_sids（） 讀取 ace->sid.sub_auth[i] for i < min（local_sid->num_subauth， ace->sid.num_subauth）。本機比較 SID （sid_everyone、sid_unix_NFS_mode 和 id_to_sid（） 結果） 一律至少有一個子授權單位，而且攻擊者會控制 ACE 修訂和授權單位位元組 （位於內界 SID 基底內），因此可以符合其中一個 SID 並強制讀取sub_auth。因此，大小 == 16 且 num_subauth >= 1 的特製 ACE 放置在安全性描述元的尾部，會導致最多超過 pntsd 配置的 SID_MAX_SUB_AUTHORITIES * sizeof（__le32） 位元組的堆積越界讀取。安全性描述元由 ksmbd_vfs_get_sd_xattr（） 載入到大小完全符合磁碟上資料 （ndr_decode_v4_ntacl（） 中的 kzalloc（sd_size） ） 的緩衝區中，因此讀取會超出配置範圍。格式錯誤的描述元可以透過SMB2_SET_INFO逐字儲存 （DACL 在寫入安全性之前不會正規化。NTACL xattr），且讀取會在後續的 SMB2_CREATE 存取檢查中觸發，讓使用 ACL xattrs 的共用上經過驗證的用戶端可存取此檢查。新增缺少的num_subauth與ace_size檢查，鏡像同級剖析器 parse_dacl（） 和 smb_inherit_dacl（） 中已存在的相同防護。
    (CVE-2026-53390)

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

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

  - hwmon：（pmbus/adm1266） 透過通訊協定大小的緩衝區退回黑匣子記錄 adm1266_pmbus_block_xfer（） 使用裝置提供的長度，將裝置提供的區塊承載複製到呼叫端提供的緩衝區中：
    memcpy（data_r， &msgs[1].buf[1]， msgs[1].buf[0]）;協助程式不知道data_r有多大，並信任裝置最多傳回一筆記錄的位元組。adm1266_nvmem_read_blackbox（） 違反了該合約：它以 ADM1266_BLACKBOX_SIZE （64 位元組） 步幅推進資料>dev_mem內部的read_buff，而協助程式願意寫入最多 ADM1266_PMBUS_BLOCK_MAX （255） 位元組。在尾端記錄上傳回超過 64 個位元組的裝置 （在 2048 位元組dev_mem配置中read_buff位移 1984） 在呼叫後 if （ret ！= ADM1266_BLACKBOX_SIZE） 傳回 -EIO 之前，最多dev_mem溢位 191 個位元組;可以拒絕回應。在呼叫端中包含修正，而不變更協助程式簽章：將每筆記錄讀取至符合協助程式最大輸出的 255 位元組本機反彈緩衝區、驗證傳回的長度，然後才將 ADM1266_BLACKBOX_SIZE 位元組精確複製到 dev_mem 插槽中。（CVE-2026-64085）

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

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

  - l2tp：在 l2tp_session_get_by_ifname 中使用 refcount_inc_not_zero l2tp_session_get_by_ifname（） 中的讀取器可以傳回指向參照計數已達到零的會話的指標。getter 使用純 refcount_inc（） 進行引用，但同一檔案中的所有其他工作階段 getter （l2tp_v2_session_get、l2tp_v3_session_get 和對應的 _get_next 變體） 都使用 refcount_inc_not_zero（），因為 IDR/RCU 查詢可以與 refcount_dec_and_test（） -> l2tp_session_free（） -> kfree_rcu（） 爭用。ifname getter 是唯一的異常值;
    在 979c017803c4 之後，在清單上提出了不一致 （L2TP：在 l2tp_session_unhash 中使用list_del_rcu）。
    rcu_read_lock_bh（） 內符合 session->ifname 的讀取器可以在 strcmp（） 和 refcount_inc（） 之間搶佔。如果最後一個參照掉落在該視窗中的另一個 CPU 上，則讀取器的 refcount_inc（） 會在已達到零的計數器上執行。refcount_t捕捉零加法，列印refcount_t：
    在 0 上加法;use-after-free，使計數器飽和，並將飽和指標傳回給呼叫端。
    會話記憶體由進行中的 RCU 讀取區段保持即時，但從 l2tp_session_free（） 排入佇列的 kfree_rcu（） 回呼將在寬限期結束後釋放它;在該點之後取消參照傳回工作階段的呼叫端會命中釋放後使用 slab-use-free。在 PREEMPT_RT local_bh_disable（） 上是每個 CPU 的休眠鎖，搶佔視窗是真實的;在庫存中 PREEMPT 核心 local_bh_disable（） 是一種preempt_count增量，在實踐中關閉了跨 CPU 爭用（見下文）。使用 refcount_inc_not_zero（） 並在失敗時繼續清單遍歷，與檔案中的其他工作階段 getter 相符。ifname getter 是 net/l2tp/ 中唯一仍然使用裸 refcount_inc（） 模式的會話 getter;此變更會還原檔案內部一致性。成功路徑不變。（CVE-2026-63918）

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

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

  - nfc： llcp：修正 llcp_sock_release（） 中的釋放後使用 llcp_sock_release（） 無條件地取消通訊端與本機通訊端清單的連結。但是，如果通訊端仍處於連接狀態，則它位於連接清單中。透過檢查通訊端狀態並從正確的清單取消連結來解決此問題。
    (CVE-2026-64011)

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

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

  - selinux：修正 avdcache 稽核 每個任務的 avdcache 錯誤地儲存和重複使用 avc_audit_required（） 計算的已稽核向量，而不是根據目前請求的權限重新計算並區分拒絕與允許的情況。因此，某些權限檢查未經過稽核，例如先前快取目錄搜尋檢查之後的目錄寫入檢查。[PM：換行調整]（CVE-2026-53367）

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

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

  - 跟蹤：如果 elt_alloc（） 失敗，則不要呼叫 map->ops->elt_free（） 在 tracing_map_elt_alloc（） 配置物件失敗的路徑中，map->ops->elt_alloc（） 呼叫從未成功。在此情況下，不應呼叫 map->ops->elt_free（）。（CVE-2026-64173）

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

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

  - net： ethernet： cortina： 使 RX SKB 每個連接埠 用於從 gmac_rx（） 中的片段組合封包的 SKB 是靜態的本地，但 Gemini 有兩個乙太網路端口，這意味著如果設備同時使用這兩個端口，則在糟糕的一天，連接埠之間可能會發生爭用。將 RX SKB 設為每個埠變數，並在埠結構中的叫用之間進行。一旦我們呼叫 napi_gro_frags（）、錯誤時（呼叫 napi_free_frags（） 之後）或連接埠停止，則將指標歸零。在一些不是絕對必要的地方將其歸零，只是為了強調正在發生的事情。這是 Sashiko 在正常補丁審查期間發現的。（CVE-2026-64056）

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

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

  - bridge：修正 sysfs 路徑中不可部分完成上下文中的睡眠 自 git 歷史記錄開始以來，brport_store（） 始終取得橋接鎖定。當時這個決定是有道理的：網橋鎖保護網橋及其埠的 STP 狀態，當時該功能僅由兩個 STP 相關屬性（成本和優先順序）使用。如今，brport_store（） 處理的屬性更多，而且大多數都不需要橋接鎖定： * 橋接標誌：只需要 RTNL。資料路徑以無鎖定方式讀取。
    可以在 net-next 中新增註釋。* FDB 連接埠刷新：只需要 FDB 鎖定。* 多點傳送屬性：只需要多點傳送鎖定。* 群組前向遮罩：僅需要 RTNL。資料路徑以無鎖定方式讀取。可以在 net-next 中新增註釋。* 備用連接埠：僅需要 RTNL。資料路徑以無鎖定方式讀取。這是一個問題，因為當某些橋接器連接埠旗標發生變化時，橋接器會呼叫 dev_set_promiscuity（），並且此函數可以自下面引用的提交以來休眠狀態，從而導致類似 [1] 的 splat。透過縮小網橋鎖定的範圍來解決此問題，並且僅在處理需要網橋鎖定的兩個STP相關屬性時才採用網橋鎖定。從 br_switchdev_set_port_flag（） 中移除現在過時的註解。SWITCHDEV_F_DEFER 旗標可以在 net-next 中移除。[1] 錯誤：從 net/core/dev_addr_lists.c：1262 的無效上下文呼叫休眠函數 in_atomic（）：1， irqs_disabled（）： 0， non_block： 0， pid： 372， name： bash preempt_count： 201， expected： 0 RCU nest depth： 0， expected： 0 5 locks held by bash/372： #0
    ffff88810c51c3f0 （sb_writers#7）{.+.+}-{0:0}， at： ksys_write （fs/read_write.c：740） #1： ffff888115ce9480 （&of->mutex）{+.+.}-{4:4}， at： kernfs_fop_write_iter （fs/kernfs/file.c：343） #2： ffff88810b9fd330 （kn->active#37）{.+.+}-{0:0}， at： kernfs_fop_write_iter （fs/kernfs/file.c：80 fs/kernfs/file.c：344） #3：
    ffffffffa59473a0 （rtnl_mutex）{+.+.}-{4:4}， at： brport_store （net/bridge/br_sysfs_if.c：326）： #4
    ffff8881099d2d58 （&br->lock）{+...}-{3:3}，在：brport_store （./include/linux/spinlock.h：348 net/bridge/br_sysfs_if.c：345） 在以下位置停用搶佔：0x0 硬體名稱：Bochs Bochs，BIOS Bochs 01/01/2011 呼叫追蹤： <TASK> dump_stack_lvl （lib/dump_stack.c：94 lib/dump_stack.c：120）
    __might_resched.cold （kernel/sched/core.c：9163） netif_rx_mode_run （net/core/dev_addr_lists.c：1262） netif_rx_mode_sync （net/core/dev_addr_lists.c：1428） dev_set_promiscuity （net/core/dev_api.c：289） br_manage_promisc （net/bridge/br_if.c：135 net/bridge/br_if.c：172） br_port_flags_change （net/bridge/br_if.c：242 net/bridge/br_if.c：747） store_learning （net/bridge/br_sysfs_if.c：79 net/bridge/br_sysfs_if.c：235）brport_store （net/bridge/br_sysfs_if.c：346） kernfs_fop_write_iter （fs/kernfs/file.c：352） new_sync_write （fs/read_write.c：595） vfs_write （fs/read_write.c：688） ksys_write （fs/read_write.c：740） do_syscall_64 （arch/x86/entry/syscall_64.c：63 arch/x86/entry/syscall_64.c：94） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） （CVE-2026-63988）

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

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

  - drm/msm/adreno：修正 a2xx-a4xx 上使用者空間觸發的當機 在 a5xx 之前，Adreno 驅動程式不會嘗試擷取 UBWC 參數 （因為這些世代無論如何都不支援 UBWC），但仍然可以從使用者空間查詢 UBWC 相關參數，從而觸發可能的 NULL 指標解除參照。檢查 adreno_get_param（） 中的 UBWC 配置，如果沒有，則傳回合理的預設值。拼湊：
    https://patchwork.freedesktop.org/patch/717778/ (CVE-2026-64049)

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

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

  - ALSA：pcm：不要設定虛假的靜音iov_iter 在轉換至 PCM 資料傳輸的 iov_iter 時，我們盲目地將iov_iter設定也用於靜音 （即資料 = NULL），這會導致虛假iov_iter的計算。幸運的是，這並沒有在大多數架構上造成問題，但現在在 RISC-V 上出了問題，導致 NULL 取消參照。處理 NULL 資料案例以處理 interleaved_copy（） 中的靜音，以解決上述錯誤。noninterleaved_copy（） 已經具有 NULL 資料處理，因此不需要變更。（CVE-2026-64134）

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

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

  - netfs：修正 netfs_invalidate_folio（） 以在所有變更都消失時清除已變更位元 如果進行串流寫入，則會使相關修改的對開本處於非最新但已變更狀態，且 netfs_folio 結構懸掛在 Folio->private 上，指示已變更範圍。隨後截斷文件，以便刪除作品集中的髒資料，但理論上保留作品集的第一部分將導致netfs_folio結構被丟棄...但會保留骯髒的旗幟。如果然後透過 mmap（） 讀取對開本，netfs_read_folio（） 會發現頁面是髒的，並跳到 netfs_read_gaps（） 以填補缺失的位。但是，netfs_read_gaps（） 預期存在netfs_folio結構，並且可以哎呀，因為截斷了它。如果對開本中的所有已變更資料都遭到清除 （如 nfs），請呼叫 netfs_invalidate_folio（） 中的 folio_cancel_dirty（） 來修正此問題。也新增一些追蹤點，以記錄對已變更頁面的修改。這可以用以下內容重現： dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1 umount /xfstest.test mount /xfstest.test xfs_io -c w 0xbbbf 0xf96c \
    -c 截斷 0xbbbf \ -c mmap -r 0xb000 0x11000 \ -c mr 0xb000 0x11000 \ /xfstest.test/foo，停用 fscaching （否則會抑制串流寫入），並變更 netfs_perform_write（） 以在 fd 開啟時不允許串流寫入 O_RDWR： if （//（file->f_mode &; FMODE_READ） || <--- 註解此內容 netfs_is_cache_enabled（ctx）） { 即使沒有此更改，它也應該是可重現的， 但如果阻止上述瑣碎的xfs_io命令重現它。請注意，初始 dd 很重要：檔案的開頭必須足夠大，以至於零點邏輯不僅會清除間隙，因為它知道檔案中還沒有任何內容可讀取。需要卸載和掛載才能清除頁面快取（還有其他方法也可以執行）。這最初是在一些移除FMODE_READ限制的修補程式上使用 generic/522 xfstest 重現的。（CVE-2026-64064）

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

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

  - mm：修正 __vm_normal_page（） 以處理對 pmd_special（）/pud_special（） 的缺失支援 在啟用 THP 的 x86 32 位元上，系統會看到 zap_huge_pmd（） 產生警告：mm/memory.c：735
    __vm_normal_page+0x6a/0x7d，來自 VM_WARN_ON_ONCE（is_zero_pfn（pfn） || is_huge_zero_pfn（pfn））;後面接著 BUG： Bad rss-counter states，然後是 BUG： 當回收調用 shrink_huge_zero_folio_scan（） 時出現錯誤的頁面狀態。就好像 _PAGE_SPECIAL 位從未在huge_zero pmd 中設定過一樣：事實上，雖然 pte_special（） 和 pte_mkspecial（） 受專用CONFIG_ARCH_HAS_PTE_SPECIAL的約束，但 pmd_special（） 和 pmd_mkspecial（） 受制於CONFIG_ARCH_SUPPORTS_PMD_PFNMAP，這在任何 32 位元架構上都不會啟用。雖然問題已透過提交 d80a9cb1a64a （mm/huge_memory 暴露：
    add 並使用 normal_or_softleaf_folio_pmd（）），這是提交 af38538801c6 中的疏忽 （mm/memory：
    從 vm_normal_page_*（）） 中分解出常見程式碼，並會導致其他問題： * smaps、pagemap （PAGE_IS_FILE） 和 numamaps 中的巨大零對開本作為檔案支援的 THP * folio_walk_start（） 即使沒有設定FW_ZEROPAGE也會傳回對開本。不過，來電者似乎可以容忍這一點。...並觸發 VM_WARN_ON_ONE（），儘管到目前為止從未報告過。要修復它，請教導 vm_normal_page_pmd（）/vm_normal_page_pud（） 考慮是否真的實現了 pmd_special/pud_special。（CVE-2026-64181）

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

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

  - hwmon：（pmbus/adm1266） 拒絕直接來自 BLACKBOX_INFO 回應的位元組 3 的record_count上難以置信的黑盒 record_count adm1266_nvmem_read_blackbox（） 迴圈。目的地緩衝區是資料>dev_mem，大小適合 nvmem 儲存格宣告的 2048 位元組 （ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64）。如果裝置報告record_count大於 32，無論是因為韌體錯誤、匯流排損毀，還是無回應的從屬返回 0xff，都會read_buff過尾端反覆運算的 dev_mem 配置結束。在進入迴圈之前，將record_count限制在 ADM1266_BLACKBOX_MAX_RECORDS （此處介紹），並在任何較大的值上傳回 -EIO，因此格式錯誤的 BLACKBOX_INFO 回應無法驅動迴圈越界。（CVE-2026-64087）

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

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

  - USB： usbtmc：檢查 URB actual_length是否有中斷 IN 通知 USBTMC 裝置可以使用選擇性中斷端點來接收通知訊息。這些通常包含指示承載格式的兩位元組標頭，但驅動程式不會在存取資料緩衝區之前檢查這些標頭是否存在。如果 URB actual_length不足以符合這些標頭，驅動程式會造成越界讀取，或取用先前通知的過時剩餘數據。檢查標頭是否包含足夠的位元組actual_data以修正，否則將 URB 重新提交至中斷端點。
    (CVE-2026-63904)

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

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

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

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

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

  - hpfs：如果hpfs_map_dnode_bitmap失敗，則修正當機 如果hpfs_map_dnode_bitmap失敗，程式碼會在未初始化的四緩衝區頭上呼叫 hpfs_brelse4，從而導致當機。（CVE-2026-63954）

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

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

  - ACPI： 按鈕：修正移除期間的 ACPI GPE 處理常式洩漏 提交 a7e23ec17fee （ACPI： 按鈕：同時安裝系統事件的通知程式） 將 ACPI 按鈕的 ACPI 通知處理常式類型變更為 ACPI_ALL_NOTIFY，但忘記更新 acpi_button_remove（） 以反映該變更。這會導致在驅動程式移除之後洩漏通知處理常式，如果在移除驅動程式之後觸發指定裝置上的 ACPI 通知，可能會導致核心損毀，並導致具有相同驅動程式之指定裝置的後續探查失敗。視需要更新 acpi_button_remove（） 中的 acpi_remove_notify_handler（） 呼叫來解決此問題。（CVE-2026-64013）

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

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

  - nvme-pci：修正資料設定錯誤上的 dma 對應洩漏 如果我們未能為 PRP 和 SGL 配置追蹤描述元，我們將在反覆運算期間洩漏初始 DMA 對應。直接取消映射迭代器;我們無法使用現有的取消映射協助程式，因為它取決於成功配置的追蹤描述元，因此會為使用中的迭代器提供新的協助程式。當驅動程式在映射 PRP 時檢測到無效bio_vec時，映射也會洩露，因此也請修復它。（CVE-2026-64019）

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

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

  - xfrm：將 MIGRATE 通知路由至呼叫端的 netns xfrm_send_migrate（） 在 net/xfrm/xfrm_user.c 中，以及 net/key/af_key.c 中的 pfkey_send_migrate（），兩者都是硬式編碼init_net，用於宣告成功 XFRM_MSG_MIGRATE / SADB_X_MIGRATE 的多點傳播。XFRM_MSG_MIGRATE 到達 per-netns NETLINK_XFRM 通訊端，而 xfrm/af_key netlink 路徑的其餘部分在 2008 年成為 netns 感知。xfrm_user.c 中的其他 14 個多點傳播路徑使用 xs_net（x）、xp_net（xp） 或 sock_net （skb->sk） 來路由其事件;僅遺漏移轉路徑。init_net硬編碼的兩個後果： 1. 通知 （選擇器、舊/新端點位址和km_address） 會傳送給 init_net 的 XFRMNLGRP_MIGRATE / pfkey BROADCAST_ALL群組上的接聽程式，而不是在發出的 netns 上。因此，在 init_net 中執行的 IKE 常駐程式會接收源自主機上任何其他 netns 的移轉通知。2. 在非 init netns 內執行並訂閱其自己的 XFRMNLGRP_MIGRATE / pfkey 群組的 IKE 常駐程式永遠不會收到其自己的移轉通知。netns 內的 IKEv2 MOBIKE / address-update 處理被無訊息地破壞。透過 km_migrate（） 和 xfrm_mgr.migrate 函式指標執行緒結構網路，刪除 xfrm_send_migrate（） 和 pfkey_send_migrate（） 中的 &init_net 覆蓋，並透過 sock_net（skb->sk）） 一直向下傳遞呼叫者的網路（已經在 xfrm_migrate（） 的範圍內）。struct xfrm_mgr 僅適用於樹狀結構，不會匯出為穩定的 API，因此函式指標簽章變更是內部的。自 pernet 轉換以來，pfkey_broadcast（） 已經透過 net_generic（net， pfkey_net_id） 感知 netns。af_key.c 中的其他五個 pfkey_broadcast（） 調用方已經傳遞了 xs_net（x）、sock_net（sk） 或 per-netns 網絡，因此這只會刪除 &init_net 異常值。（CVE-2026-63914）

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

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

  - USB：serial：mxuport：修正小型端點的記憶體損毀 請確定大量端點封包大小上限至少為 8 個位元組，以避免在惡意裝置報告較小大小時使用者控制的 slab 損毀。（CVE-2026-63899）

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

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

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

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

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

  - PCI：mediatek-gen3：當找不到 IRQ 時，防止洩漏 IRQ 網域 在 mtk_pcie_setup_irq（） 中，IRQ 網域是在擷取控制器的 IRQ 之前配置的。如果後者失敗，函數會直接傳回錯誤，而不會清理分配的網域。因此，請反轉順序，以便在找到控制器的 IRQ 之後配置 IRQ 網域。Sashiko 在審查 [PATCH v6 0/7] PCI 時標記了這一點：mediatek-gen3：新增電源控制支援。（CVE-2026-63862）

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

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

  - efi：在 ACPI init 之前配置執行階段工作佇列，自提交 5894cf571e14 以來 （acpi/prmt：使用 EFI 執行階段沙箱叫用 PRM 處理常式） ACPI PRM 呼叫會委派給在核心執行緒中執行的工作佇列，讓您更容易偵測和緩解韌體所執行的錯誤記憶體存取。Rafael 報告說，此類 PRM 存取可能發生在 efisubsys_init（） 執行之前，這是工作佇列的分配位置，導致 NULL 指標解除參照。由於 acpi_init（） [觸發早期 PRM 存取] 也以 subsys_initcall（） 的形式執行，並且有自己的依賴關係，可能對 initcall 順序敏感，因此延遲 acpi_init（） 不是一個選項。因此，請改為將工作佇列分配拆分為自己的 postcore initcall，因為這是唯一允許進行 EFI 執行階段呼叫的缺失部分。如此可確保在 subsys_initcall（） 層級執行的所有程式碼都可以存取 EFI 執行階段呼叫 （包括 PRM 呼叫）。（CVE-2026-64183）

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

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

  - ip6： vti：在 vti6_changelink（） 中使用 ip6_tnl.net。ip netns 新增 ns1 ip netns 新增 ns2 ip -n ns1 連結 新增vti6_test類型 vti6 remote ：：1 local ：：2 key 7 ip -n ns1 連結集 vti6_test netns ns2 ip -n ns2 連結集 vti6_test 類型 vti6 remote ：：3 local ：：4 key 9 ip netns del ns2 ip netns del ns1 [ 132.495484]
    ------------[ 切到這裡 ]------------ [ 132.497609] net/core/dev.c：12376 的核心錯誤！提交 61220ab34948 （vti6：啟用命名空間變更） 從 vti6 裝置丟棄NETIF_F_NETNS_LOCAL。然後，vti6 隧道可以通過IFLA_NET_NS_FD。移動後，dev_net（dev） 指向新的 netns，而 t->net 則停留在建立的 netns。vti6_changelink（） 和 vti6_update（） 仍然使用 dev_net（dev） 和 dev_net（t->dev）。它們從每個 netns 雜湊中取消連結，然後重新連結到另一個。建立 netns 會留下一個過時的項目。
    netns 稍後會遍歷釋放的記憶體的 cleanup_net（）。可從無特權的使用者命名空間 （unshare --user --map-root-user --net） 連線。容器主機上的跨租用戶範圍。（CVE-2026-63917）

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

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

  - mm/vmalloc：不要在 BH 已停用的上下文上觸發 BUG（），如果 in_interrupt（） 傳回 true，則 __get_vm_area_node（） 目前會觸發 BUG（）。但是，當停用 BH 時，in_interrupt（） 也會報告 true。橋接器程式碼可以在停用下半部分的情況下呼叫 rhashtable_lookup_insert_fast（）：__vlan_add（） -> br_fdb_add_local（） spin_lock_bh（&br->hash_lock）; <-- Disable BH -> fdb_add_local（） -> fdb_create（） -> rhashtable_lookup_insert_fast（） -> kvmalloc（） -> vmalloc（） -> __get_vm_area_node（） -> BUG_ON（in_interrupt（）） spin_unlock_bh（&br->hash_lock） 即使調用方不在 NMI 或硬式 IRQ 上下文中，這仍會觸發 BUG（）。將 in_interrupt（） 檢查替換為 in_nmi（） ||in_hardirq（）。
    (CVE-2026-63955)

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

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

  - IIO：陀螺儀：ITG3200：修正 I2C 讀取錯誤堆疊位置 itg3200_read_all_channels（） 需要「__be16
    *buf' 做為參數，並將i2c_msg目的地填入為 '（char *）&buf'。由於 'buf' 是參數 （指標），因此 '&buf' 是 itg3200_read_all_channels（） 堆疊上本機指標插槽的位址，而不是呼叫端掃描緩衝區的位址。（char *） 轉換會隱藏類型不相符。因此，i2c_transfer（） 將 ITG3200_SCAN_ELEMENTS * sizeof（s16） = 8 位元組寫入參數的堆疊槽，當函數傳回時，該槽將被丟棄。調用方在 itg3200_trigger_handler（） 中的掃描緩衝區永遠不會被寫入，因此 iio_push_to_buffers_with_timestamp（） 每次掃描都會通過 /dev/iio：deviceX 將未初始化的堆棧內容推送到用戶空間——這既是功能錯誤（沒有實際的陀螺儀或溫度數據通過觸發的緩衝區傳遞）還是信息洩露。非緩衝的 read_raw（） 路徑不受影響：它會經過 itg3200_read_reg_s16（），該 （） 在本機 s16 值上使用 '&out'，這是正確的。刪除虛假的「&」，以便 i2c 讀取寫入呼叫端的緩衝區。（CVE-2026-63934）

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

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

  - ipv4：在 unregister_net_sysctl_table（） 之後釋放 net->ipv4.sysctl_local_reserved_ports ipv4_sysctl_exit_net（） 目前釋放 net->ipv4.sysctl_local_reserved_ports 過早。只有在 unregister_net_sysctl_table（） 之後，我們才能確定沒有執行緒可以使用 sysctl，包括 /proc/sys/net/ipv4/ip_local_reserved_ports。（CVE-2026-64002）

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

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

  - i2c：tegra：修正 mutex_lock 失敗時的pm_runtime洩漏 如果 tegra_i2c_mutex_lock（） 失敗，則函數會傳回而不呼叫 pm_runtime_put（），從而洩漏先前 pm_runtime_get_sync（） 所取得的執行階段 PM 參照。這可防止裝置進入執行階段暫停狀態。在鎖定失敗時返回之前新增缺少的 pm_runtime_put（）。（CVE-2026-64171）

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

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

  - drm/xe/oa：修正exec_queue在 xe_oa_stream_open_ioctl（） 中，當 param.exec_q->width > 1 時，函式直接傳回 -EOPNOTSUPP，跳過現有的err_exec_q清理路徑。xe_exec_queue_lookup（） 獲得的exec_queue參照被洩露。exec 佇列會保留 xe_file 上的參照，該參照只會在佇列拆卸期間捨棄。洩漏的查詢參照不在檔案的 exec_queue xarray 上，因此檔案關閉無法釋放它。這會使 exec 佇列和檔案私有狀態無限期地固定。跳到err_exec_q而不是直接返回，以便釋放引用。（從提交 339fa0be9e4a5d69fa47e91f4a36574224fb478f 中挑選）（CVE-2026-64021）

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

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

  - thunderbolt： property：拒絕 tb_property_entry_valid（） 中的 u32 換行，entry->value 為 u32，entry->length 為 u16;總和以 u32 和換行執行。惡意 XDomain 對等節點可以選擇值 = 0xffffff00、長度 = 0x100，因此總和0x100000000換行為 0 並通過> block_len檢查。然後，tb_property_parse（） 將 entry->value 作為屬性區塊的 dword 位移量傳遞給 parse_dwdata（），讀取攻擊者導向的記憶體遠遠超過配置。對於具有 deviceid 或 vendorid 金鑰的 TEXT 類型項目，它位於 xd->device_name / xd->vendor_name 中，並且可透過 per-XDomain device_name / vendor_name sysfs 屬性讀取回來;洩漏是 NUL 限制的 （kstrdup（） 在第一個零位元組停止） 且無目標 （攻擊者選擇增量，而不是絕對位址）。DATA 類型的項目會剖析成 property->value.data，但不會一般顯示給使用者空間。使用 check_add_overflow（） 以拒絕包裝總和。（CVE-2026-63893）

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

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

  - net： mctp： usb：修正 urb 完成與 rx_retry 取消之間的爭用 設定 ->stopped 和取消 rx_retry 工作 （ndo_stop） 之間的排序可能會讓我們的 urb 排入佇列： T1： ndo_stop T2： rx_retry_work ------------ ---------------- LD： ->stopped => false ST： ->stopped <= true usb_kill_urb（） mctp_usb_rx_queue（） usb_submit_urb（） cancel_delayed_work_sync（） 然後該 urb 完成可以重新排程rx_retry_work。透過在新的 rx 鎖定下以不可部分完成方式更新停止 （防止再次重新排隊） 和取消之間的排序。設定 ->rx_stopped 並取消擱置工作之後，我們知道無法重新排隊，因此剩下的就是終止任何擱置中的 urb。
    (CVE-2026-63874)

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

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

  - net/iucv：修正 .getsockopt 鏡像 iucv_sock_setsockopt（） 中的鎖定，並將整個交換器包裝在 lock_sock（）/release_sock（） 中。先前存在的僅SO_MSGLIMIT鎖定會變得多餘並遭到移除。任何 AF_IUCV HIPER 使用者都可能透過使用 getsockopt（SO_MSGSIZE） 爭用 recvmsg（） 來損毀核心：在 iucv_sock_close（） （從爭用的 recvmsg（） 呼叫） 將 hs_dev iucv->hs_dev->mtu 設定為 NULL 後，SO_MSGSIZE 臂會解除參照 iucv--mtu，從而產生 NULL 指標解除參照。（CVE-2026-64004）

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

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

  - USB：typec：altmodes/displayport：在讀取狀態更新 VDO 之前驗證計數 損壞/惡意裝置可能會為狀態更新 VDO 傳送不正確的計數，這將導致核心讀取未初始化的堆疊資料並將其發送到其他地方。透過正確驗證更新物件的計數來修正此問題。（CVE-2026-63961）

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

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

  - RDMA/ionic：在結構ib_device中以 %.64s node_desc[64] 綁定node_desc sysfs 讀取不保證是 NUL- 終止的。核心 IB sysfs 處理常式正是出於這個原因而使用 %.64s （drivers/infiniband/core/sysfs.c：1307），因為 node_desc_store（） 執行最多 IB_DEVICE_NODE_DESC_MAX 位元組的原始 memcpy，沒有 NUL 終止：memcpy（desc.node_desc， buf， min_t（int， count， IB_DEVICE_NODE_DESC_MAX））;如果透過 node_desc sysfs 檔案寫入恰好 64 個位元組，則陣列不包含 NUL 位元組。ionic hca_type_show（） 處理常式使用不受限制的 %s，並將在node_desc結尾讀入結構ib_device的相鄰欄位，直到遇到 NUL。Ionic 支援IB_DEVICE_MODIFY_NODE_DESC，因此這是可由使用者空間觸發的。比對核心處理常式並繫結格式說明元。（CVE-2026-53371）

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

ID	名稱	嚴重性
328201	Linux Distros 未修補弱點：CVE-2026-63876	high
328200	Linux Distros 未修補弱點：CVE-2026-64110	high
328199	Linux Distros 未修補弱點：CVE-2026-63842	high
328198	Linux Distros 未修補弱點：CVE-2026-63821	medium
328197	Linux Distros 未修補弱點：CVE-2026-63887	critical
328196	Linux Distros 未修補弱點：CVE-2026-64075	high
328195	Linux Distros 未修補弱點：CVE-2026-64005	high
328194	Linux Distros 未修補弱點：CVE-2026-64028	medium
328193	Linux Distros 未修補弱點：CVE-2026-15187	medium
328192	Linux Distros 未修補弱點：CVE-2026-64158	high
328191	Linux Distros 未修補弱點：CVE-2026-63932	medium
328190	Linux Distros 未修補弱點：CVE-2026-64039	high
328189	Linux Distros 未修補弱點：CVE-2026-63820	medium
328188	Linux Distros 未修補弱點：CVE-2026-64129	medium
328187	Linux Distros 未修補弱點：CVE-2026-64035	critical
328186	Linux Distros 未修補弱點：CVE-2026-63920	high
328185	Linux Distros 未修補弱點：CVE-2026-53390	high
328184	Linux Distros 未修補弱點：CVE-2026-64085	high
328183	Linux Distros 未修補弱點：CVE-2026-63918	high
328182	Linux Distros 未修補弱點：CVE-2026-64011	high
328181	Linux Distros 未修補弱點：CVE-2026-53367	medium
328180	Linux Distros 未修補弱點：CVE-2026-64173	medium
328179	Linux Distros 未修補弱點：CVE-2026-64056	critical
328178	Linux Distros 未修補弱點：CVE-2026-63988	high
328177	Linux Distros 未修補弱點：CVE-2026-64049	medium
328176	Linux Distros 未修補弱點：CVE-2026-64134	high
328175	Linux Distros 未修補弱點：CVE-2026-64064	high
328174	Linux Distros 未修補弱點：CVE-2026-64181	high
328173	Linux Distros 未修補弱點：CVE-2026-64087	high
328172	Linux Distros 未修補弱點：CVE-2026-63904	medium
328171	Linux Distros 未修補弱點：CVE-2026-63849	high
328170	Linux Distros 未修補弱點：CVE-2026-63954	high
328169	Linux Distros 未修補弱點：CVE-2026-64013	medium
328168	Linux Distros 未修補弱點：CVE-2026-64019	high
328167	Linux Distros 未修補弱點：CVE-2026-63914	high
328166	Linux Distros 未修補弱點：CVE-2026-63899	high
328165	Linux Distros 未修補弱點：CVE-2026-63843	high
328164	Linux Distros 未修補弱點：CVE-2026-63862	medium
328163	Linux Distros 未修補弱點：CVE-2026-64183	medium
328162	Linux Distros 未修補弱點：CVE-2026-63917	high
328161	Linux Distros 未修補弱點：CVE-2026-63955	high
328160	Linux Distros 未修補弱點：CVE-2026-63934	high
328159	Linux Distros 未修補弱點：CVE-2026-64002	high
328158	Linux Distros 未修補弱點：CVE-2026-64171	high
328157	Linux Distros 未修補弱點：CVE-2026-64021	high
328156	Linux Distros 未修補弱點：CVE-2026-63893	high
328155	Linux Distros 未修補弱點：CVE-2026-63874	high
328154	Linux Distros 未修補弱點：CVE-2026-64004	high
328153	Linux Distros 未修補弱點：CVE-2026-63961	medium
328152	Linux Distros 未修補弱點：CVE-2026-53371	medium

偵測

Nessus 的 Misc. 系列

high

high

high

medium

critical

high

high

medium

medium

high

medium

high

medium

medium

critical

high

high

high

high

high

medium

medium

critical

high

medium

high

high

high

high

medium

high

high

medium

high

high

high

high

medium

medium

high

high

high

high

high

high

high

high

high

medium

medium