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

  - net/sched： sch_sfb：將直接出隊呼叫替換為 peek 和 qdisc_dequeue_peeked 當 sfb 有 peek（） 回呼為 qdisc_peek_dequeued（） 的子項 （例如 qfq qdisc） 時，我們可能會發生核心錯誤。當此類 qdisc 的父項（例如，在修補程式 #3 中如 tbf）想要從其子項（在本例中為 sfb）擷取 skb 時，它將執行以下操作： 1a. 執行 peek（） - 當感應到子項可以提供 skb 時，則 - 本例中的子項 （sfb） 會呼叫其子項 （qfq） 的 peek。 qfq 做了正確的事，並將返回gso_skb佇列封包。注意：如果沒有gso_skb項目，則 qfq 會將其儲存在那裡。1b.
    叫用子系 （sfb） 上的 dequeue（）。問題就在這裡。- sfb 將調用子項的 dequeue（），它本質上只是嘗試獲取 qfq 隊列中的一些內容。[ 127.594489][ T453] KASAN：範圍 [0x0000000000000048-0x000000000000004f] [ 127.594741][ T453] CPU：2 UID：0 PID：453 通訊：
    ping 未受污染 7.1.0-rc1-00035-gac961974495b-dirty #793 PREEMPT（full） [ 127.595059][ T453] 硬體名稱：Bochs Bochs， BIOS Bochs 01/01/2011 [ 127.595254][ T453] RIP： 0010：qfq_dequeue+0x35c/0x1650 [sch_qfq] [ 127.595461][ T453] 代碼：00 fc ff df 80 3c 02 00 0f 85 17 0e 00 00 4c 8d 73 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 76 0c 00 00 48b8 00 00 00 00 00 00 fc ff df 4c 8b [ 127.596081][ T453] RSP： 0018：ffff88810e5af440 EFLAGS： 00010216 [ 127.596337][ T453] RAX：
    dffffc000000000000 RBX：00000000000000000 RCX：dffffc0000000000000 [ 127.596623][ T453] RDX：0000000000000009 RSI：0000001880000000 RDI：ffff888104fd82b0 [ 127.596917][ T453] RBP：ffff888104fd8000 R08：
    ffff888104fd8280 ： 1ffff110211893a3 [ 127.597165][ T453] R10： 1ffff110211893a6 R11： 1ffff110211893a7 R12： 0000001880000000 [ 127.597404][ T453] R13： ffff888104fd82b8 R14： 0000000000000048 R15：R09
    0000000040000000 [ 127.597644][ T453] FS：00007fc380cbfc40（0000） GS：ffff88816f2a8000（0000） knlGS：00000000000000000 [ 127.597956][ T453] CS：0010 DS：0000 ES：0000 CR0：0000000080050033 [127.598160][ T453] CR2：00005610aa9890a8 CR3：000000010369e000 CR4：0000000000750ef0 [ 127.598390][ T453] PKRU：55555554 [ 127.598509][ T453] 呼叫追蹤：[ 127.598629][ T453] T453127.598718<TASK> [ ][ ] ？ mark_held_locks+0x40/0x70 [ 127.598890][ T453] ？ srso_alias_return_thunk+0x5/0xfbef5 [ 127.599053][ T453] sfb_dequeue+0x88/0x4d0 [ 127.599174][ T453] ？ ktime_get+0x137/0x230 [ 127.599328][ T453] ？ srso_alias_return_thunk+0x5/0xfbef5 [ 127.599480][ T453] ？ qdisc_peek_dequeued+0x7b/0x350 [sch_qfq] [127.599670][ T453] ？ srso_alias_return_thunk+0x5/0xfbef5 [ 127.599831][ T453] tbf_dequeue+0x6b1/0x1098 [sch_tbf] [ 127.599988][ T453] __qdisc_run+0x169/0x1900 在 b 中#1正確的做法是將 skb 從佇列中抓取gso_skb。此修補程式集透過將 b 更改 #1為使用 qdisc_dequeue_peeked（） 方法來解決該問題。（CVE-2026-64012）

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

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

  - 已解決 Linux 核心中的下列弱點：cifs: Fix busy dentry used after unmounting Since commit 340cea84f691c (cifs: open files should not hold ref on superblock), cifs file only holds the dentry ref_cnt, the cifs file close work(cfile->deferred) could be executed after unmounting, which will trigger a warning in generic_shutdown_super: BUG: Dentry 00000000a14a6845{i=c,n=file} still in use (1) [unmount of cifs cifs] The detailed processs is: process A process B kworker fd = open(PATH) vfs_open file->__f_path = *path // dentry->d_lockref.count = 1 cifs_open cifs_new_fileinfo cfile->dentry = dget(dentry) // dentry->d_lockref.count = 2 close(fd) __fput cifs_close queue_delayed_work(deferredclose_wq, cfile->deferred) dput(dentry) // dentry->d_lockref.count = 1 smb2_deferred_work_close _cifsFileInfo_put list_del(&cifs_file->flist) umount cleanup_mnt deactivate_super cifs_kill_sb cifs_close_all_deferred_files_sb cifs_close_all_deferred_files // cannot find cfile, skip
    _cifsFileInfo_put kill_anon_super generic_shutdown_super shrink_dcache_for_umount umount_check WARN ! // dentry->d_lockref.count = 1 cifsFileInfo_put_final dput(cifs_file->dentry) // dentry->d_lockref.count = 0 Fix it by flushing 'deferredclose_wq' before calling kill_anon_super. Fetch a reproducer in https://bugzilla.kernel.org/show_bug.cgi?id=221548. (CVE-2026-64108)

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

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

  - 已解決 Linux 核心中的下列弱點：firmware: arm_ffa: Check for NULL FF-A ID table while driver registration The bus match callback assumes that every FF-A driver provides an id_table and dereferences it unconditionally. Enforce that contract at registration time so a buggy client driver cannot crash the bus during match. (CVE-2026-64166)

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

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

  - 已解決 Linux 核心中的下列弱點：nfsd: fix dead ACL conflict guard in nfsd4_create nfsd4_create() steals create->cr_dpacl/cr_pacl into the local nfsd_attrs via the designated initializer, then immediately sets the source pointers to NULL. The subsequent conflict guard tests the already-nilled source fields, making it permanently dead code: if (create->cr_acl) { if (create->cr_dpacl || create->cr_pacl) /* always false */ When a client encodes both FATTR4_WORD0_ACL and FATTR4_WORD2_POSIX_{DEFAULT,ACCESS}_ACL in the same CREATE fattr bitmap, nfsd4_acl_to_attr() overwrites attrs.na_pacl/na_dpacl without releasing the originals, leaking two posix_acl slab objects per request.
    Repeated requests cause unbounded slab exhaustion. Fix by checking attrs.na_dpacl/na_pacl (the stolen values) instead of the nilled create->cr_dpacl/cr_pacl, matching the correct pattern already used in nfsd4_setattr(). (CVE-2026-53395)

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

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

  - gpio： aggregator：修正潛在的釋放後使用 在錯誤時，我們會在從查詢表中移除項目之前釋放 aggr->lookups->dev_id。如果並發執行緒在我們刪除項目之前呼叫 gpiod_find（），它可以迭代列表並調用 gpiod_match_lookup_table（），這在調用 strcmp（） 時無條件地取消參照 dev_id。反轉清理順序。（CVE-2026-64023）

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

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

  - macsec：修正 XPN lower-PN 包裝處的重播保護 在 macsec_post_decrypt（） 中，當 pn U32_MAX時，pn + 1 將 u32 溢位為 0，並且第一個分支永遠不會觸發。如果 next_pn_halves.lower 也在上半部分，則 pn_same_half（pn， lower） 為 true，XPN else-if 也不會觸發，next_pn_halves保持不變。然後，在 XPN 關聯上捕獲帶有 pn == 0xFFFFFFFF 的合法幀的攻擊者可以無限期地重播它，因為 lowest_pn 永遠不會超過捕獲的 pn 並且 macsec_decrypt（） 重建相同的 IV。擴充 XPN else-if 以在 pn + 1 換行至 0 時也觸發，因此接收 pn == U32_MAX 會next_pn_halves （upper + 1， 0）。（CVE-2026-63925）

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

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

  - wifi： mac80211：限制注入的天線索引 ieee80211_parse_tx_radiotap 剖析注入幀的 radiotap 標頭時，ieee80211_parse_tx_radiotap（） 直接使用 IEEE80211_RADIOTAP_ANTENNA 值作為移位計數：info->control.antennas |= BIT（*iterator.this_arg）;*iterator.this_arg 是直接從使用者空間提供的框架中取得的 8 位元值，因此可以要求 BIT（） 最多移動 255。這是未簽名長的未定義行為，由 UBSAN 報告： UBSAN：net/mac80211/tx.c：2174：30 中的移位越界 移位指數 235 對於 64 位元類型「無符號長」來說太大 呼叫追蹤：
    ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c：2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c：2451 ...packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c：3109 info->control.antennas 是 2 位元點陣圖 （u8 天線：2），因此只能表示天線索引 0 和 1。忽略任何較大的值，而不是移出邊界。（CVE-2026-63869）

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

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

  - 已解決 Linux 核心中的下列弱點：pds_core: fix debugfs_lookup dentry leak and error handling debugfs_lookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery. Additionally, when CONFIG_DEBUG_FS is disabled, debugfs_lookup() returns ERR_PTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash. (CVE-2026-64147)

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

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

  - iio： buffer： hw-consumer：修正錯誤路徑中的釋放後使用 在 iio_hw_consumer_alloc（） 的err_put_buffers清理路徑中，程式碼使用 list_for_each_entry（） 在呼叫 iio_buffer_put（） 時反覆運算緩衝區，如果 refcount 降至 0，則可以釋放目前的緩衝區。然後，list_for_each_entry（） 迴圈巨集評估 buf->head.next 以繼續迭代，存取釋放的緩衝區。使用 list_for_each_entry_safe（） 修正此問題。（CVE-2026-63930）

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

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

  - 已解決 Linux 核心中的下列弱點：mm/damon/sysfs-schemes: call missing mem_cgroup_iter_break() damon_sysfs_memcg_path_to_id() breaks mem_cgroup_iter() loop without calling mem_cgroup_iter_break(). This leaks the cgroup reference. Fix the issue by calling mem_cgroup_iter_break() before the break. The issue was discovered [1] by Sashiko. (CVE-2026-64184)

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

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

  - USB：serial：digi_acceleport：修正小型端點的記憶體損毀 新增缺少的大量緩衝區大小健全性檢查，以避免在惡意裝置報告的緩衝區小於預期時發生越界記憶體存取或 slab 損毀。（CVE-2026-63901）

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

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

  - USB：typec：wcove：不要在 wcove_read_rx_buffer（） 中寫入過去的結構pd_message wcove_read_rx_buffer（） 將 PD RX FIFO 複製到調用方的結構pd_message中，其中包含 for （i = 0; i < USBC_RXINFO_RXBYTES（info）;
    i++） regmap_read（wcove->regmap， USBC_RX_DATA + i， msg + i）;它有兩個問題：USBC_RXINFO_RXBYTES（） 是一個 5 位字段（最多 31），而結構pd_message是 30 位元組（__le16標頭 + __le32 payload[PD_MAX_PAYLOAD]，打包）。RXINFO 中閂鎖的位元組計數是埠夥伴放在線上的位元組數，因此如果 WCOVE BMC 接收器未在硬體中強制執行 PD 物件計數限制，則傳輸 31 位元組框架的惡意夥伴可以驅動迴圈超過目的地一個位元組。現有的 FIXME 將其標記為未經驗證。獨立地，regmap_read（） 採用一個無符號的 int *，並在目的地儲存一個完整的無符號 int。傳遞位元組指標 msg + i 表示每次反覆運算寫入四個位元組;高三個為零（val_bits為 8），通常會被下一個迭代覆蓋，但最終迭代的高位元組則不然。對於 RXBYTES == 30，i == 29 迭代已經寫入了 msg 之後的三個零位元組，它位於 wcove_typec_irq（） 中 IRQ 線程的堆棧上。將迴圈限制為 sizeof（struct pd_message），並在僅儲存其低位元組之前將每個暫存器讀取到本地，因此無論 RXINFO 報告什麼，副本都永遠不會超過目的地。（CVE-2026-63960）

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

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

  - HID：wacom：修正 wacom_hid_set_device_mode（） 中的 OOB 寫入 wacom_hid_set_device_mode（） 目前假設 HID_DG_INPUTMODE 使用始終位於功能報告的第一個欄位 （field[0]） 中。
    不過，裝置可以在不同的欄位中指定HID_DG_INPUTMODE。如果HID_DG_INPUTMODE位於第一個欄位以外的欄位中，且第一個欄位的report_count小於HID_DG_INPUTMODE usage_index，則會導致越界寫入 r->field[0]->value。透過在特徵映射期間將 HID_DG_INPUTMODE 的欄位索引儲存在「struct hid_data」中來解決此問題。在wacom_hid_set_device_mode（）中，使用這個儲存的欄位索引來存取正確的欄位，並新增邊界檢查，以確保欄位索引和值索引在寫入前都在有效範圍內。
    (CVE-2026-63916)

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

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

  - USB：serial：safe_serial：修正具有小型端點的記憶體損毀 請確定大量緩衝區大小至少為 8 個位元組，以避免在惡意裝置報告較小大小時，在安全模式下使用者控制的 slab 損毀。（CVE-2026-63957）

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

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

  - IIO：化學：SCD30：修正 write_raw 中的除以零 設定取樣頻率時，在將 val2 用作除數之前，先對 val2 進行零檢查。將零小數部分寫入 sampling_frequency sysfs 屬性的使用者會觸發核心中的除以零。（CVE-2026-63931）

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

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

  - USB： serial： cypress_m8： validate interrupt packet headers cypress_read_int_callback（） 會根據選取的 Cypress 封包格式剖析中斷輸入緩衝區。格式 1 具有兩個位元組的狀態/計數標頭，而格式 2 具有一個位元組的結合狀態/計數標頭。usb-serial核心會從端點描述元的wMaxPacketSize調整中斷輸入緩衝區的大小，而當未設定URB_SHORT_NOT_OK時，成功的中斷傳輸可以完成短時間。在讀取封包之前，請檢查已完成的封包是否包含選取的標頭。系統會忽略格式錯誤的短報表，並透過現有的重試路徑重新提交中斷 URB，以防止越界標頭位元組讀取。KASAN 報告如下： cypress_read_int_callback+0x240/0x7f0 中的 KASAN slab-out-of-bounds 讀取大小為 1 呼叫追蹤：cypress_read_int_callback（） （drivers/usb/serial/cypress_m8.c：1009） __usb_hcd_giveback_urb（） dummy_timer（） [ johan：在標頭長度健全性檢查中使用常數 ] （CVE-2026-63902）

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

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

  - 已解決 Linux 核心中的下列弱點：netfs: Fix folio->private handling in netfs_perform_write() Under some circumstances, netfs_perform_write() doesn't correctly manipulate folio->private between NULL, NETFS_FOLIO_COPY_TO_CACHE, pointing to a group and pointing to a netfs_folio struct, leading to potential multiple attachments of private data with associated folio ref leaks and also leaks of netfs_folio structs or netfs_group refs. Fix this by consolidating the place at which a folio is marked uptodate in one place and having that look at what's attached to folio->private and decide how to clean it up and then set the new group. Also, the content shouldn't be flushed if group is NULL, even if a group is specified in the netfs_group parameter, as that would be the case for a new folio. A filesystem should always specify netfs_group or never specify netfs_group. The Sashiko auto-review tool noted that it was theoretically possible that the fpos >= ctx->zero_point section might leak if it modified a streaming write folio. This is unlikely, but with a network filesystem, third party changes can happen. It also pointed out that __netfs_set_group() would leak if called multiple times on the same folio from the whole folio modify section. (CVE-2026-64059)

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

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

  - 已解決 Linux 核心中的下列弱點：fs/statmount: fix slab out-of-bounds write in statmount_mnt_idmap statmount_mnt_idmap() writes one mapping with seq_printf() and then manually advances seq->count to include the NUL separator. If seq_printf() overflows, seq_set_overflow() sets seq->count to seq->size. The manual seq->count++ changes this to seq->size + 1. seq_has_overflowed() then no longer detects the overflow. The corrupted count returns to statmount_string(), which later executes:
    seq->buf[seq->count++] = '\0'; This causes a 1-byte NULL out-of-bounds write on the dynamically allocated seq buffer. Fix this by checking for overflow immediately after seq_printf(). (CVE-2026-64074)

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

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

  - 已解決 Linux 核心中的下列弱點：iio: imu: adis16550: fix stack leak in trigger handler adis16550_trigger_handler() declares the scan data array on the stack without initializing it. The memcpy() at the bottom fills only the first 28 bytes (TEMP + 6 channels of GYRO/ACCEL data), and iio_push_to_buffers_with_timestamp() writes the s64 timestamp at the 8-byte-aligned offset 32. Bytes 28-31 remain uninitialized stack data which leaks to userspace on ever trigger. Fix this all by just zero-initializing the structure on the stack. (CVE-2026-63966)

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

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

  - 已解決 Linux 核心中的下列弱點：dma-buf: fix UAF in dma_buf_fd() tracepoint Once FD_ADD() returns, the fd is live in the file descriptor table and a thread sharing that table can close() it before DMA_BUF_TRACE() runs. The close drops the last reference, __fput() frees the dma_buf, and the tracepoint then dereferences dmabuf to take dmabuf->name_lock -- slab-use-after-free.
    Split FD_ADD() back into get_unused_fd_flags() + fd_install() and emit the tracepoint between them. While the fdtable slot is reserved with a NULL file pointer, a racing close() returns -EBADF without entering
    __fput(), so the dma_buf stays alive across the trace. Same approach as commit 2d76319c4cbb (dma-buf: fix UAF in dma_buf_put() tracepoint). This undoes the FD_ADD() conversion done in commit 34dfce523c90 (dma:
    convert dma_buf_fd() to FD_ADD()); FD_ADD() has no place to hook the tracepoint safely. (CVE-2026-63910)

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

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

  - USB： serial： mct_u232：修正缺少的中斷輸入傳輸健全性檢查 新增中斷輸入傳輸大小的遺失健全性檢查，以避免剖析過時或未初始化的 slab 資料 （並將其洩漏給使用者空間）。（CVE-2026-63897）

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

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

  - usbip： vudc：修正 vudc_remove 中由於爭用情形造成的釋放後使用錯誤 此修補程式是 Zheng Wang 在 2023 年關於 vudc_remove（） 中釋放後使用的報告的後續內容。原始執行緒因 Shuah Khan 要求對取消插拔/解除綁定路徑進行運行時測試而停滯不前。該補丁提供了該測試並保持了 Zheng 的原始修復形狀。在 vudc_probe（） 中，v_init_timer（） 將 udc->tr_timer.timer 綁定到 v_timer（）。
    usbip_sockfd_store（） 透過 v_start_timer（）/v_kick_timer（） 啟動計時器。然後，vudc_remove（） 可以在計時器仍處於擱置或執行狀態時釋放包含的結構 vudc。KASAN 確認未修補的 x86_64 QEMU 客體上的爭用，其中 CONFIG_KASAN=y、CONFIG_USBIP_VUDC=y、CONFIG_USB_ZERO=y，以及一個緊密迴圈，重複將通訊端 fd 寫入 usbip_sockfd、關閉通訊端對，並取消綁定/重新綁定 usbip-vudc.0： 錯誤： KASAN：__run_timer_base.part.0+0x8ba/0x8e0 中的 slab-use-after-free 透過任務 trigger_and_unb/239 在 addr ffff888001b80740 寫入大小 8 由任務 239 分配： vudc_probe+0x4d/0xaa0 由任務 239 釋放：kfree+0x18f/0x520 device_release_driver_internal+0x388/0x540 unbind_store+0xd9/0x100 這會落在計時器核心而不是 v_timer（） 本身，因為嵌入的 timer_list 在包含其包含的結構 vudc 已經被釋放後被遍歷。潛在的終身錯誤與 Zheng 報告的錯誤相同。
    從 vudc_remove（） 呼叫 v_stop_timer（） 並同步刪除計時器後，同一工具完成了 5000 次綁定/解除綁定迭代，沒有 KASAN 報告。（CVE-2026-63905）

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

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

  - 已解決 Linux 核心中的下列弱點：firmware: arm_ffa: Snapshot notifier callbacks under lock Both notification handlers currently look up a notifier callback under notify_lock, drop the lock, and then dereference the returned notifier entry. A concurrent unregister can delete and free that entry in the gap, leaving the handler to dereference stale memory. Copy the callback pointer and callback data while notify_lock is still held and invoke the callback only after the lock is dropped. This keeps the existing callback execution model while removing the use-after-free window in both the framework and non-framework notification paths. (CVE-2026-64080)

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

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

  - thunderbolt： property：拒絕 dir_len < 4 以防止size_t下溢在非 root 路徑上，
    __tb_property_parse_dir（） 從 entry->length 中獲取dir_len（u16 擴大為 size_t）。當 entry->length < 4： 1 時，會遵循兩個不同的 OOB 條件。非根路徑以 kmemdup（&block[dir_offset]， sizeof（*dir->uuid） 開頭，一律從 dir_offset 讀取 4 個 dword。tb_property_entry_valid（） 僅強制執行 dir_offset + entry->length <= block_len，因此dir_offset接近屬性區塊末尾且 entry->length 為 0..3 的特製項目會通過該門，但允許 UUID 副本從區塊中運行（例如，dir_offset = 497,500 dword 區塊中的 dir_len = 3 讀取區塊 [497..501]）。2. 在 kmemdup 之後，content_len = dir_len - 4 個反向溢位size_t到 ~SIZE_MAX，nentrytries 變為 SIZE_MAX / 4，並且項目遍歷在每次迭代中運行 OOB，直到項目驗證失敗或核心在未映射的頁面上 oops。
    拒絕 UUID kmemdup 之前 * 非根路徑上的 dir_len < 4，這會關閉兩個漏洞。此外，將 INIT_LIST_HEAD（&dir->properties） 上移到目錄分配之後，以便調用 tb_property_free_dir（） 的新錯誤返回路徑（和現有的 uuid-alloc 失敗路徑）看到一個可行走的列表，而不是 list_for_each_entry_safe（） 會失敗的零初始化 NULL next/prev。（CVE-2026-63892）

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

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

  - 輸入：xpad - 修正「共用」按鈕的越界存取 xpadone_process_packet（） 直接從 urb->actual_length 接收 len，並使用它為 data[len - 18] 或 data[len - 26] 處的共用按鈕位元組編製索引。
    由於 len 和 data[0] 都在設備的控制之下，因此損壞的控制器可以發送actual_length < 18（例如 5 位元組）的GIP_CMD_INPUT封包並到達此程式碼路徑，從而導致超出實際陣列的存取。透過計算偏移量並檢查封包長度的邊界來修正此問題。（CVE-2026-63943）

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

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

  - 已解決 Linux 核心中的下列弱點：wifi: mac80211: bounds-check link_id in ieee80211_ml_epcs IEEE80211_MLE_STA_EPCS_CONTROL_LINK_ID is 0x000f, so link_id extracted from a PRIO_ACCESS ML element PER_STA_PROFILE subelement can be 0..15. sdata->link[] has IEEE80211_MLD_MAX_NUM_LINKS (15) entries (indices 0..14), making index 15 out-of-bounds. A connected WiFi 7 AP can trigger this by sending an EPCS Enable Response action frame with a PER_STA_PROFILE subelement where link_id = 15. The unsolicited-notification path (dialog_token = 0) is reachable any time EPCS is already enabled, without any prior client request. sdata->link[15] reads into the first word of sdata->activate_links_work (a wiphy_work whose embedded list_head is non-NULL after INIT_LIST_HEAD), so the NULL check on the result does not catch the invalid access. The garbage pointer is then passed to ieee80211_sta_wmm_params(), which dereferences link->sdata and crashes the kernel. The same class of bug was fixed for ieee80211_ml_reconfiguration() by commit 162d331d833d (wifi: mac80211: bounds-check link_id in ieee80211_ml_reconfiguration). (CVE-2026-64030)

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

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

  - 已解決 Linux 核心中的下列弱點：mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN. If we run with init_on_free, we will zero out pages during __free_pages_prepare(), to skip zeroing on the allocation path. However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will consequently not only skip clearing page content, but also skip clearing tag memory. Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that will get mapped to user space through set_pte_at() later: set_pte_at() and friends will detect that the tags have not been initialized yet (PG_mte_tagged not set), and initialize them. However, for the huge zero folio, which will be mapped through a PMD marked as special, this initialization will not be performed, ending up exposing whatever tags were still set for the pages. The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state that allocation tags are set to 0 when a page is first mapped to user space. That no longer holds with the huge zero folio when init_on_free is enabled. Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to tag_clear_highpages() whether we want to also clear page content. Invert the meaning of the tag_clear_highpages() return value to have clearer semantics. Reproduced with the huge zero folio by modifying the check_buffer_fill arm64/mte selftest to use a 2 MiB area, after making sure that pages have a non-0 tag set when freeing (note that, during boot, we will not actually initialize tags, but only set KASAN_TAG_KERNEL in the page flags). $ ./check_buffer_fill 1..20 ... not ok 17 Check initial tags with private mapping, sync error mode and mmap memory not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory ...
    This code needs more cleanups; we'll tackle that next, like decoupling __GFP_ZEROTAGS from
    __GFP_SKIP_KASAN. [akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David] (CVE-2026-64130)

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

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

  - 1.3.9c 和 1.3.10rc3 之前的 ProFTPD 在 mod_sftp 模組中包含一個堆積型緩衝區溢位弱點，允許經過驗證的低權限攻擊者透過傳送超過 fxp.c 元件中 16 KB 重組緩衝區的特製 SFTP 封包片段來實現任意程式碼執行。攻擊者可以提供過大的片段來觸發條件不正確的重新分配、損毀集區免費清單中繼資料、覆寫root_fs BSS 全域指標以參照虛假檔案系統結構，以及透過特製的 RENAME 要求將 pr_fsio_stat（） 重新導向到 system（）。（CVE-2026-63090）

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

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

  - 已解決 Linux 核心中的下列弱點：bpf: Propagate error from visit_tailcall_insn Commit e40f5a6bf88a (bpf: correct stack liveness for tail calls) added visit_tailcall_insn() but did not check its return value. (CVE-2026-63864)

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

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

  - FreeRDP 之前 3.28.0 （透過 3.27.1影響） 3.x 在剖析 .rdp 連線檔的 selectedmonitors 欄位時，在 freerdp_client_rdp_file_apply_to_settings（） （client/common/file.c） 中包含雙重釋放弱點。MonitorIds 陣列是透過 settings 物件配置，而且會在 strtoul 錯誤路徑上釋放指向它的原始非擁有指標，而不會清除 settings->MonitorIds，使其懸置;在拆卸時，freerdp_settings_free（） 再次釋放相同的緩衝區。如果攻擊者說服受害者使用超大的監視器權杖開啟特製的 .rdp 檔案，就可以在預設設定的任何 FreeRDP CLI 用戶端 （xfreerdp/sdl-freerdp/wlfreerdp） 中觸發大小控制的雙重釋放。（CVE-2026-64621）

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

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

  - 隧道：不要假設 iptunnel_pmtud_check_icmp（） 中的傳輸標頭 在某些情況下，可以在未設定 skb 傳輸標頭的情況下呼叫 iptunnel_pmtud_check_icmp（）。這會觸發越界存取，因為 （typeof（skb->transport_header））~0U 為 65535。在確保 skb 線性部分中存在 icmp->type 後，根據 IPv4 網路標頭存取 icmp 標頭。請注意，iptunnel_pmtud_check_icmpv6（）） 沒問題。（CVE-2026-63992）

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

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

  - batman-adv： bla：避免透過丟棄介面對宣告進行 NULL-ptr 解除參照 如果沒有保留rtnl_lock，hardif 可能會被擷取為 meshif 的主要介面，但隨後（在此介面上操作時）會與網狀介面分離。在此情況下，meshif 仍然存在，但從主要 hardif 到 meshif 的指標設定為 NULL。在繼續使用 meshif 傳送 ARP 要求之前，必須先檢查mesh_iface是否為非 NULL。（CVE-2026-64094）

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

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

  - 已解決 Linux 核心中的下列弱點：ASoC: codecs: pcm512x: fix null-ptr dereference in pcm512x_overclock_xxx_put() In the pcm512x chipset driver, pcm512x_overclock_xxx_put() is defined as a general mixer kcontrol instead of a DAPM kcontrol, so struct snd_soc_dapm_context must not be accessed via snd_soc_dapm_kcontrol_to_dapm(). This causes a NULL pointer dereference, so it must be modified to use snd_soc_component_to_dapm(). (CVE-2026-64107)

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

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

  - 已解決 Linux 核心中的下列弱點：mm/migrate_device: fix pgtable leak in migrate_vma_insert_huge_pmd_page When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due to a PMD check failure, the pgtable allocated earlier via pte_alloc_one() is never freed, causing a memory leak. Added free_abort label to release the pgtable in error path. (CVE-2026-63953)

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

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

  - USB：musb：omap2430：修正 omap2430_probe（） 中的釋放後使用 在 omap2430_probe（） 中，在最後一次存取 np 之前過早呼叫 of_node_put（np），如果節點的參照計數降至零，則會導致釋放後使用。在成功和錯誤路徑中上次使用 np 之後移動 of_node_put（） 呼叫。
    (CVE-2026-63906)

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

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

  - 已解決 Linux 核心中的下列弱點：iio: adc: mt6359: fix unchecked return value in mt6358_read_imp In mt6358_read_imp(), the variable val_v is passed to regmap_read() but the return value is not checked. If the read fails, val_v remains uninitialized and its random stack content is subsequently reported as a measurement result. Initialize val_v to zero to ensure a predictable value is reported in case of bus failure and to prevent potential stack data leakage. This also satisfies static analyzers that might otherwise flag the variable as used uninitialized. (CVE-2026-63936)

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

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

  - 已解決 Linux 核心中的下列弱點：erofs: fix managed cache race for unaligned extents After unaligned compressed extents were introduced, the following race could occur:
    [Thread 1] [Thread 2] (z_erofs_fill_bio_vec) <handle a Z_EROFS_PREALLOCATED_FOLIO folio> ...
    filemap_add_folio (1) (z_erofs_bind_cache) <the same folio is found..> .. .. folio_attach_private (2) filemap_add_folio (3) again Since (1) is executed but (2) hasn't been executed yet, it's possible that another thread finds the same managed folio in z_erofs_bind_cache() for a different pcluster and calls filemap_add_folio() again since folio->private is still Z_EROFS_PREALLOCATED_FOLIO. Fix this by explicitly clearing folio->private before making the folio visible in the managed cache so that another pcluster can simply wait on the locked managed folio as what we did for other shared cases [1]. This only impacts unaligned data compression (`-E48bit` with zstd, for example). [1] Commit 9e2f9d34dd12 (erofs: handle overlapped pclusters out of crafted images properly) was originally introduced to handle crafted overlapped extents, but it addresses unaligned extents as well. (CVE-2026-64031)

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

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

  - net： garp：修正 garp_pdu_parse_attr 中無正負號的整數反向溢位 接收端 GARP 屬性剖析器會計算具有反向運算元的 dlen： dlen = sizeof（*ga） - ga->len;ga->len 是線上屬性長度，包括 GARP 屬性標頭。對於具有資料的一般屬性，ga->len 大於 sizeof（*ga），因此減法在無符號算術中溢位。結果值稍後會傳遞給 garp_attr_lookup（），其長度參數為 u8。截斷之後，剖析的資料長度通常不再符合為本機註冊屬性儲存的長度，因此會忽略收到的 Join/Leave 事件。這會中斷常見屬性（如GVRP VLAN註冊屬性）的GARP接收路徑。將資料長度計算為屬性長度減去標頭長度。（CVE-2026-63868）

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

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

  - 已解決 Linux 核心中的下列弱點：iio: adc: nxp-sar-adc: fix division by zero in write_raw Add a validation check for the sampling frequency value before using it as a divisor. A user writing zero or a negative value to the sampling_frequency sysfs attribute triggers a division by zero in the kernel. Also prevent unsigned integer underflow when the computed cycle count is smaller than NXP_SAR_ADC_CONV_TIME, which would wrap the u32 inpsamp to a huge value. (CVE-2026-63935)

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

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

  - 已解決 Linux 核心中的下列弱點：bridge: mcast: Fix a possible use-after-free when removing a bridge port When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The reverse happens when per-VLAN multicast snooping is disabled. When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled. The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port: # ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcast_vlan_snooping 1 # ip link set dev br1 type bridge mcast_snooping 0 # ip link set dev br1 type bridge mcast_snooping 1 This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, br_multicast_disable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when flushing VLANs. After this commit, br_multicast_disable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1]. Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled. [1] ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5:
    swapper/5/0 [...] Call Trace: <IRQ> __debug_check_no_obj_freed (lib/debugobjects.c:1116) kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobject_cleanup (lib/kobject.c:689) rcu_do_batch (kernel/rcu/tree.c:2617) rcu_core (kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622)
    __irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irq_exit_rcu (kernel/softirq.c:752) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) </IRQ> (CVE-2026-64032)

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

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

  - 藍牙：hci_sync：在發佈 rcu_read_lock（） 和 hci_dev_lock（hdev） 後，修正 hci_le_create_cis_sync hci_le_create_cis_sync（） 取消參照 conn->conn_timeout 中的 UAF。conn 指標是透過 hdev->conn_hash.list 從受 RCU 保護的反覆運算取得，一旦卸除這些鎖定，這些鎖定就無效。並行中斷連接可以釋放解鎖和取消參照之間的hci_conn，導致釋放後讀取。hci_conn_del（） 中的取消機制無法阻止這種情況，因為 hci_le_create_cis_pending（） 佇列hci_create_cis_sync data=NULL：hci_cmd_sync_queue（hdev， hci_create_cis_sync， NULL， NULL）;當 hci_conn_del（） 以 data=conn 出隊時：hci_cmd_sync_dequeue（hdev， NULL， conn， NULL）;由於 NULL ！= conn，因此 _hci_cmd_sync_lookup_entry（） 中的查詢永遠不會相符，而且擱置中的工作專案不會取消。透過在鎖定仍保留時將 conn->conn_timeout 儲存到本機變數中來修正此問題，因此過時的 conn 指標在解鎖後永遠不會取消參照。這與提交 035c25007c9e （藍牙：hci_sync：修正 le_read_features_complete 上的 UAF） 修正的錯誤類別相同，後者解決了不同函式中的相同模式。此弱點是使用開源自動化安全性稽核平台 （https://github.com/0sec-labs0sec.ai） 識別的。（CVE-2026-63944）

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

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

  - 已解決 Linux 核心中的下列弱點：net: ena: PHC: Check return code before setting timestamp output ena_phc_gettimex64() is setting the output parameter regardless of whether ena_com_phc_get_timestamp() succeeded or failed. When ena_com_phc_get_timestamp() returns an error, the timestamp parameter may contain uninitialized stack memory (e.g., when PHC is disabled or in blocked state) or invalid hardware values. Passing these to userspace via the PTP ioctl is both a security issue (information leak) and a correctness bug. Fix by checking the return code after releasing the lock and only setting the output timestamp on success. (CVE-2026-63837)

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

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

  - 已解決 Linux 核心中的下列弱點：mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap() The mmap_prepare hook functionality includes the ability to invoke mmap_prepare() from the mmap() hook of existing 'stacked' drivers, that is ones which are capable of calling the mmap hooks of other drivers/file systems (e.g. overlayfs, shm). As part of the mmap_prepare action functionality, we deal with errors by unmapping the VMA should one arise. This works in the usual mmap_prepare case, as we invoke this action at the last moment, when the VMA is established in the maple tree. However, the mmap() hook passes a not-fully-established VMA pointer to the caller (which is the motivation behind the mmap_prepare() work), which is detached. So attempting to unmap a VMA in this state will be problematic, with the most obvious symptom being a warning in vma_mark_detached(), because the VMA is already detached. It's also unncessary - the mmap() handler will clean up the VMA on error. So to fix this issue, this patch propagates whether or not an mmap action is being completed via the compatibility layer or directly. If the former, then we do not attempt VMA cleanup, if the latter, then we do. This patch also updates the userland VMA tests to reflect the change. (CVE-2026-53373)

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

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

  - 已解決 Linux 核心中的下列弱點：firmware: arm_ffa: Validate framework notification message layout Framework notifications carry an indirect message in the shared RX buffer.
    Validate the reported offset and size before using them, reject zero-length payloads, and ensure that any non-header payload starts at the UUID field rather than in the middle of the message header. Use the validated offset and size values for both kmemdup() and the UUID parsing path so malformed firmware data cannot drive an out-of-bounds read or an oversized allocation. (CVE-2026-64081)

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

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

  - 已解決 Linux 核心中的下列弱點：RDMA/rtrs: Fix use-after-free in path file creation cleanup In the error path of rtrs_srv_create_path_files(), the sysfs root folders may already have been created and srv_path->kobj may already have been initialized. If a later step fails, the cleanup currently calls kobject_put(&srv_path->kobj) before rtrs_srv_destroy_once_sysfs_root_folders(srv_path). kobject_put() may drop the last reference to srv_path->kobj and invoke the release callback, rtrs_srv_release(), which frees srv_path. The following call to rtrs_srv_destroy_once_sysfs_root_folders(srv_path) then dereferences srv_path internally to access srv_path->srv, resulting in a use-after-free. This failure path is reached before rtrs_srv_create_path_files() returns success, so the successful-path lifetime handling is not involved.
    Fix this by destroying the sysfs root folders before calling kobject_put(&srv_path->kobj), so srv_path is still valid while the helper accesses it. This issue was found by a static analysis tool I am developing.
    (CVE-2026-64033)

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

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

  - ip6： vti：在 vti6_siocdevprivate（） 中使用 ip6_tnl.net。在本系列的修補程式 1/2 之後，vti6_update（） 會透過 t->net 取消連結並重新連結通道。vti6_siocdevprivate（） 仍然使用 dev_net（dev） 進行衝突查詢。對於通過IFLA_NET_NS_FD移動的隧道，dev_net（dev） 是新的 netns，而不是 t->net。
    然後，在已遷移的隧道上運行 SIOCCHGTUNNEL： net = dev_net（dev） /* 遷移的 netns */ t = vti6_locate（net， &p1， false） /* 錯過 t->net 中的目標 */ ...t = netdev_priv（dev） vti6_update（t， &p1， false） /* 改變 t->net 的雜湊 */ 移轉的 netns 中的呼叫端會挑選符合建立 netns 中通道的參數。
    dev_net（dev） 中的查詢找不到任何內容。vti6_update（） 會在這些參數的建立 netns 雜湊儲存貯體的頭部加上移轉的通道。建立 netns 中稍後的查詢會解析為移轉的裝置。xfrm 接收會透過呼叫端控制的裝置傳遞相符的封包。可從無特權的使用者命名空間 （unshare --user --map-root-user --net） 連線。容器主機上的跨租用戶範圍。
    切換非後援裝置上的 SIOCCHGTUNNEL 路徑，以使用 t->net 進行查詢。查詢現在符合 netns vti6_update（） 操作。另外，在查詢之前新增 ns_capable（self->net->user_ns， CAP_NET_ADMIN）。案例頂端的檢查是針對 dev_net（dev）->user_ns，移轉後就是攻擊者的 netns。那裡的調用者可以選擇 self->net 中不存在的參數，查詢返回 NULL，t 變成 self，並且 vti6_update（） 將設備插入創建 netns 哈希中。新的檢查也需要在建立 netns user_ns中CAP_NET_ADMIN。後援裝置上的 SIOCADDTUNNEL 和 SIOCCHGTUNNEL 會保留 dev_net（dev），這等於那裡的 init_net。（CVE-2026-63921）

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

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

  - 已解決 Linux 核心中的下列弱點：iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf() iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes, kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial kref to 1. It then calls dma_resv_add_fence() which takes a second reference (kref=2), and stores a raw pointer in block->fence. On the success path the function returns without calling dma_fence_put() to release the initial reference, so every buffer enqueue permanently leaks one kmalloc-128 allocation. The iio_buffer_cleanup() work item only releases the temporary reference taken during completion signalling by iio_buffer_signal_dmabuf_done();
    the initial reference from dma_fence_init() is never released. With four iio_rwdev instances at 240kHz and 512 samples per buffer, this produces ~1875 kmalloc-128 allocations per second matching the observed slab growth exactly. A test with ftrace confirmed that the dma_fence_destroy event was never triggered. Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring ownership of the fence to the DMA reservation object. The DMA fence then gets properly discarded after being signalled. (CVE-2026-63929)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/amdgpu: check num_entries in GEM_OP GET_MAPPING_INFO kvcalloc(args->num_entries, sizeof(*vm_entries), GFP_KERNEL) at amdgpu_gem.c:1050 uses the user-supplied num_entries directly without any upper bounds check. Since num_entries is a __u32 and sizeof(drm_amdgpu_gem_vm_entry) is 32 bytes, a large num_entries produces an allocation exceeding INT_MAX, triggering WARNING in __kvmalloc_node_noprof(), causing a kernel WARNING, TAINT_WARN, and panic on CONFIG_PANIC_ON_WARN=y systems. Add a size bounds check before we invoke the kvzalloc() to reject oversized num_entries early with -EINVAL. (cherry picked from commit 1fe7bf5457f6efd7be60b17e23163ba54341d73d) (CVE-2026-63878)

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

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

  - xfrm： esp：還原組合的單一片段長度閘門 ESP 錯位快速路徑會在 esp_output_tail（） 配置目的地頁面片段之前，在 esp_output_head（） 中附加預告片。頭側閘門目前分別檢查 skb->data_len 和 tailen，但尾部代碼從組合後拖車 skb->data_len 中分配一個目的地碎片。當組合對齊長度超過頁面時，拒絕頁面片段快速路徑。否則，skb_page_frag_refill（） 可能會回歸到單個頁面，而目標 sg 仍然跨越組合的 skb->data_len。還原 IPv4 和 IPv6 的此組合長度分頁閘道。（CVE-2026-63912）

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

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

  - iio： imu： st_lsm6dsx：修正標記的 FIFO 緩衝區中的堆疊洩漏 標記的 FIFO 路徑在堆疊上宣告了 __aligned（8） 但沒有初始化程式的 iio_buff，但結構中有一個漏洞，然後隨著ST_LSM6DSX_SAMPLE_SIZE位元組 （6） 的複製，該漏洞將洩漏到使用者空間，但該漏洞與時間戳記之間的空間不會初始化。提交 c14edb4d0bdc （iio：imu：st_lsm6dsx 修正對齊方式和資料洩漏問題） 將未標記的 FIFO 路徑移至 hw->scan 中的 kzalloc 緩衝區，但對於標記的路徑，它只新增了對齊限定詞，而沒有新增初始化運算式:(只需將堆疊上的結構初始化為零即可解決此問題。（CVE-2026-63967）

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

ID	名稱	嚴重性
328321	Linux Distros 未修補弱點：CVE-2026-64012	medium
328320	Linux Distros 未修補弱點：CVE-2026-64108	high
328319	Linux Distros 未修補弱點：CVE-2026-64166	medium
328318	Linux Distros 未修補弱點：CVE-2026-53395	high
328317	Linux Distros 未修補弱點：CVE-2026-64023	high
328316	Linux Distros 未修補弱點：CVE-2026-63925	high
328315	Linux Distros 未修補弱點：CVE-2026-63869	high
328314	Linux Distros 未修補弱點：CVE-2026-64147	medium
328313	Linux Distros 未修補弱點：CVE-2026-63930	high
328312	Linux Distros 未修補弱點：CVE-2026-64184	medium
328311	Linux Distros 未修補弱點：CVE-2026-63901	high
328310	Linux Distros 未修補弱點：CVE-2026-63960	medium
328309	Linux Distros 未修補弱點：CVE-2026-63916	high
328308	Linux Distros 未修補弱點：CVE-2026-63957	high
328307	Linux Distros 未修補弱點：CVE-2026-63931	medium
328306	Linux Distros 未修補弱點：CVE-2026-63902	medium
328305	Linux Distros 未修補弱點：CVE-2026-64059	medium
328304	Linux Distros 未修補弱點：CVE-2026-64074	high
328303	Linux Distros 未修補弱點：CVE-2026-63966	high
328302	Linux Distros 未修補弱點：CVE-2026-63910	high
328301	Linux Distros 未修補弱點：CVE-2026-63897	high
328300	Linux Distros 未修補弱點：CVE-2026-63905	high
328299	Linux Distros 未修補弱點：CVE-2026-64080	critical
328298	Linux Distros 未修補弱點：CVE-2026-63892	medium
328297	Linux Distros 未修補弱點：CVE-2026-63943	high
328296	Linux Distros 未修補弱點：CVE-2026-64030	high
328295	Linux Distros 未修補弱點：CVE-2026-64130	medium
328294	Linux Distros 未修補弱點：CVE-2026-63090	high
328293	Linux Distros 未修補弱點：CVE-2026-63864	high
328292	Linux Distros 未修補弱點：CVE-2026-64621	critical
328291	Linux Distros 未修補弱點：CVE-2026-63992	critical
328290	Linux Distros 未修補弱點：CVE-2026-64094	medium
328289	Linux Distros 未修補弱點：CVE-2026-64107	medium
328288	Linux Distros 未修補弱點：CVE-2026-63953	medium
328287	Linux Distros 未修補弱點：CVE-2026-63906	high
328286	Linux Distros 未修補弱點：CVE-2026-63936	medium
328285	Linux Distros 未修補弱點：CVE-2026-64031	high
328284	Linux Distros 未修補弱點：CVE-2026-63868	high
328283	Linux Distros 未修補弱點：CVE-2026-63935	medium
328282	Linux Distros 未修補弱點：CVE-2026-64032	high
328281	Linux Distros 未修補弱點：CVE-2026-63944	high
328280	Linux Distros 未修補弱點：CVE-2026-63837	medium
328279	Linux Distros 未修補弱點：CVE-2026-53373	high
328278	Linux Distros 未修補弱點：CVE-2026-64081	high
328277	Linux Distros 未修補弱點：CVE-2026-64033	critical
328276	Linux Distros 未修補弱點：CVE-2026-63921	high
328275	Linux Distros 未修補弱點：CVE-2026-63929	high
328274	Linux Distros 未修補弱點：CVE-2026-63878	medium
328273	Linux Distros 未修補弱點：CVE-2026-63912	critical
328272	Linux Distros 未修補弱點：CVE-2026-63967	high

偵測

Nessus 的 Misc. 系列

medium

high

medium

high

high

high

high

medium

high

medium

high

medium

high

high

medium

medium

medium

high

high

high

high

high

critical

medium

high

high

medium

high

high

critical

critical

medium

medium

medium

high

medium

high

high

medium

high

high

medium

high

high

critical

high

high

medium

critical

high