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

  - Net：：CIDR：：Set 版本 0.20 透過 Perl 未驗證網路遮罩。網路遮罩的遮罩部分可以包含 Unicode 數字，例如阿拉伯文-印度文 （U+0661） 或非數字，這些數字會被忽略。這可讓網路遮罩接受更大的網路。前導零也被接受，但被視為十進制而不是八進制。這可能會導致人們對哪些網路是可以接受的混淆。
    (CVE-2026-49942)

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

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

  - Net：：CIDR：：Set Perl 版本 0.20 未驗證 IP 位址。稱為
    _encode解析位址的方法。如果位址看起來不像網路遮罩或網路範圍，則會假設它們為單一 IP 位址，並以 32 位元或 128 位元網路遮罩的形式傳回給自己。如果引數不是格式正確的 IP 位址，則會導致無限遞迴。攻擊者可利用此弱點造成拒絕服務。(CVE-2026-49941)

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

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

  - regulator： core：修正 regulator_resolve_supply（） 錯誤路徑中的鎖定 如果在 regulator_resolve_supply（） 中延遲啟用電源穩壓器失敗，則程式碼目前會觸發 lockdep 警告： 警告：
    drivers/regulator/core.c：2649，_regulator_put+0x80/0xa0， CPU#6：kworker/u32：4/596 ... 呼叫追蹤：
    _regulator_put+0x80/0xa0 （P） regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8因為調用時必須持有regulator_list_mutex
    _regulator_put（）。要解決此問題，只需切換到使用 regulator_put（） 即可。同時，我們還應該確保在清除供應指標時不會對我們的 rdev 進行並發訪問。添加適當的鎖定以確保。雖然有問題的程式碼將在後續提交中完全刪除，但我相信在刪除之前更正這一點以供將來參考仍然是有益的。
    (CVE-2026-46252)

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

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

  - AppArmor：允許 apparmor 處理未對齊的 dfa 表 dfa 表可以源自核心或使用者空間，而且不一定保證 8 位元組對齊，因此可能會在各種架構上觸發未對齊的記憶體存取。導致以下 [ 73.901376] 警告： CPU：0 PID：341 at security/apparmor/match.c：316 aa_dfa_unpack+0x6cc/0x720 [ 74.015867] 連結於以下模組：binfmt_misc evdev flash sg drm drm_panel_orientation_quirks背光i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_commonmdio_bus usb_common [74.428977] CPU：0 UID：0 PID：341 通訊：apparmor_parser 未受污染 6.18.0-rc6+ #9 無 [ 74.536543] 呼叫追蹤：[ 74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [ 74.633757]<0000000000476438> []
    __warn+0xd8/0x100 [ 74.696664]<00000000004296d4> [] warn_slowpath_fmt+0x34/0x74 [ 74.771006]<00000000008db28c> [] aa_dfa_unpack+0x6cc/0x720 [ 74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [74.910545 []<00000000008e7740> unpack_profile+0xbe0/0x1300 [ 74.984888]<00000000008e82e0> [] aa_unpack+0xe0/0x6a0 [ 75.051226]<00000000008e3ec4> [] aa_replace_profiles+0x64/0x1160 [ 75.130144]<00000000008d4d90> [] policy_update+0xf0/0x280 [ 75.201057]<00000000008d4fc8> [] profile_replace+0xa8/0x100 [ 75.274258]<0000000000766bd0> [] vfs_write+0x90/0x420 [ 75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [ 75.406932]<0000000000767174> [] sys_write+0x14/0x40 [ 75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [ 75.548802] ---[ 結束追蹤 0000000000000000000 ]--- [75.609503] DFA blob 資料流0xfff0000008926b96未對齊。[ 75.682695] TPC[8db2a8] 的核心未對齊存取 aa_dfa_unpack+0x6e8/0x720 使用 get_unaligned_xx（） 協助程式來解決此問題。
    (CVE-2026-46254)

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

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

  - OP-TEE 是一個可信執行環境 （TEE），旨在作為在 Arm 上運行的非安全 Linux 核心的伴侶;使用 TrustZone 技術的 Cortex-A 核心。從版本 4.3.0 和之前的版本 4.11.0開始，處理來自正常世界的FFA_MEM_SHARE要求時，OP-TEE OS 中存在類型混淆弱點。這僅適用於將 OP-TEE 設定為 S-EL0 SP 的 SPMC 時，即使用「CFG_CORE_SEL1_SPMC=y」和「CFG_SECURE_PARTITION=y」。4.11.0 版已修正此問題。 (CVE-2026-45702)

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

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

  - nfc：hci：shdlc：在釋放上下文之前停止計時器和工作 llc_shdlc_deinit（） 會清除 SHDLC skb 佇列並釋放 llc_shdlc 結構，而其計時器和狀態機器工作可能仍處於作用中狀態。計時器回呼可以排程sm_work，sm_work存取 SHDLC 狀態和 skb 佇列。如果卸除與佇列/執行中的工作專案平行發生，可能會導致 UAF 和其他關機爭用。停止所有 SHDLC 計時器並同步取消sm_work，再清除佇列並釋放內容。由 Linux Verification Center (linuxtesting.org) 和 SVACE 發現。(CVE-2026-46267)

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

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

  - procfs：修正在 do_task_stat（） 中讀取 real_parent 時缺少的 RCU 保護 當讀取 /proc/[pid]/stat 時，do_task_stat（） 會在沒有適當 RCU 保護的情況下存取 task->real_parent，這會導致：
    cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu（delayed_put_task_struct） task_tgid_nr_ns（var） rcu_read_lock <--- Too late to protect task->real_parent！ task_pid_ptr <--- UAF！ rcu_read_unlock 此修補程式使用 task_ppid_nr_ns（） 而不是 task_tgid_nr_ns（） 來新增適當的 RCU 保護以存取 task->real_parent。（CVE-2026-46259）

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

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

  - OP-TEE 是一個可信執行環境 （TEE），旨在作為在 Arm 上運行的非安全 Linux 核心的伴侶;使用 TrustZone 技術的 Cortex-A 核心。從版本和 3.16.0 之前 4.11.0開始，OP-TEE SPMC/SP 流程內 FF-A 的共用記憶體拆卸邏輯中存在釋放後使用者 （UAF） 爭用情形。這僅適用於將 OP-TEE 設定為 S-EL0 SP 的 SPMC 時，即使用「CFG_SECURE_PARTITION=y」。負責釋放 'smem->receivers' 和 'smem->regions' 中的項目的函數 'sp_mem_remove（）' 在執行 'free（）' 操作之前無法取得全域 'sp_mem_lock'。同時，其他程式碼路徑 （例如 'sp_mem_get_receiver（）'） 會在不持有鎖定的情況下反覆運算這些相同的清單，或者像 'sp_mem_is_shared（）' 一樣，在持有鎖定的同時反覆運算，但不會針對 'sp_mem_remove（）' 中未受保護的 'free（）' 進行序列化。這會建立跨執行緒爭用，其中迭代清單的執行緒可以取得指向條目的指標（例如，「struct sp_mem_map_region」或「struct sp_mem_receiver」），然後另一個執行緒呼叫「sp_mem_remove（）」，從而釋放物件。當第一個執行緒繼續並取消參照指標時，會導致釋放後使用弱點。4.11.0 版已修正此問題。 (CVE-2026-40290)

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

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

  - jupyter-server 版本1.12.02.17.0中的弱點允許攻擊者在使用「allow_origin_pat」設定時繞過 CORS 來源驗證。此問題的原因是使用「re.match（）」來驗證「Origin」標頭，該標頭僅錨定在字串的開頭。這允許攻擊者控制的網域 （例如「trusted.example.com.evil.com」通過針對旨在符合「trusted.example.com」的模式的驗證。該漏洞影響程式碼庫中的多個位置，包括 CORS 標頭、WebSocket 連線、引用程式驗證和登入重新導向，從而可能啟用網路釣魚攻擊、任意程式碼執行以及未經授權存取敏感的 API 回應。（CVE-2026-6657）

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

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

  - PCI： 端點：新增 alloc_workqueue（） 的 NULL 檢查 alloc_workqueue（） 可以在記憶體配置失敗時傳回 NULL。如果沒有適當的錯誤檢查，稍後使用 epf_ntb_epc_init（） 中的 NULL 工作佇列指標呼叫 queue_work（） 時，可能會導致 NULL 指標解除參照。在 alloc_workqueue（） 之後立即新增 NULL 檢查，並在失敗時傳回 -ENOMEM，以防止驅動程式使用無效的工作佇列指標載入。（CVE-2025-71313）

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

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

  - daphne before 4.2.2 會從 Twisted 的剖析標頭重建原始 HTTP 要求，並將其饋送至 autobahn 以進行 WebSocket 交握處理。Twisted 不會將 \x0b、\x0c、\x1c、\x1d、\x1e 或 \x85 視為標頭行分隔符號，但 autobahn 會將標頭值解碼為 str 並呼叫 splitlines（）。攻擊者可以利用此剖析器差異，將額外的標頭插入傳遞給應用程式的 ASGI 範圍。
    Daphne 現在會拒絕任何標頭值中包含這些位元組的要求，並具有 400 回應。（CVE-2026-44546）

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

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

  - unicodedata.normalize（） 在處理特製的 Unicode 輸入時，可能會佔用過多的 CPU 時間，其中包含長時間的組合字元與交替的標準組合類別值。這會影響所有正規化表單。（CVE-2026-3276）

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

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

  - OpenStack Mistral 透過 22.0.0 允許在 API 公開時執行任意遠端程式碼。有些端點允許程式碼執行，這可能會導致服務憑證外洩。
    (CVE-2026-41283)

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

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

  - daphne 之前 4.2.2 未將 maxFramePayloadSize 或 maxMessagePayloadSize 傳遞至 Autobahn 的 WebSocketServerFactory。由於 Autobahn 將這兩個值預設為 0 （無限制），因此未經驗證的遠端攻擊者可能會傳送任意大的 WebSocket 訊息或框架，從而造成過多的記憶體消耗和拒絕服務。（CVE-2026-44545）

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

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

  - GitHub CLI （gh） 是 GitHub 的官方命令行工具。在之前 2.93.0，GitHub CLI 會透過 gh attestation、gh release verify 和 gh release verify-asset 命令，在 TUF 存放庫鏡像的 API 要求中錯誤地包含授權標頭。CLI 使用具有鑑別層的共用 HTTP 用戶端，可自動將權杖附加至傳出要求。此層缺乏準確的主機偵測，並且可能會錯誤地將目標主機歸因，從而為其提供永遠不應該接收的權杖。具體而言，主機正規化邏輯會摺疊任何 *.github.com 子網域以 github.com，因此對 tuf-repo.github.com （GitHub Pages 網站，而非 GitHub API 端點） 的請求會被視為 github.com 請求，並接收使用者的 github.com 權杖。對於完全不符合 github.com 或已知 GHES 執行個體的主機，解析器會回復為 GH_ENTERPRISE_TOKEN （如果已設定）。gh attestation、gh release verify 和 gh release verify-asset 命令會從數個外部主機擷取資料，作為其正常作業的一部分 （來自 tuf-repo.github.com 和 tuf-repo-cdn.sigstore.dev 的 TUF 中繼資料、來自 Azure Blob 儲存體） 的成品套件組合。由於這些要求會透過相同的已驗證 HTTP 用戶端，因此權杖會傳送給所有要求。此弱點已在 2.93.0 中修正。(CVE-2026-48501)

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

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

  - gpib：修正 ni_usb_init（） 中的記憶體洩漏 在 ni_usb_init（） 中，如果 ni_usb_setup_init（） 失敗，函數會傳回 -EFAULT，而不釋放分配的寫入緩衝區，從而導致記憶體洩漏。此外，ni_usb_setup_init（） 在失敗時傳回 0，這會導致 ni_usb_init（） 傳回 -EFAULT，這是這種情況的不適當錯誤代碼。透過釋放錯誤路徑中的寫入來修正洩漏。修改 ni_usb_setup_init（） 以在失敗時傳回 -EINVAL，並將此錯誤碼傳播到 ni_usb_init（） 中。
    (CVE-2026-45939)

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

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

  - ovpn： tcp - 不要在 tcp_close（） 之後取消參照 NULL sk_socket成員 在 keepalive 到期的情況下刪除對等體時，該對等體會從 OpenVPN 雜湊表中移除，並暫時插入版本清單中以供進一步處理。這發生在： ovpn_peer_keepalive_work（） unlock_ovpn（release_list） 此處理程序包括透過還原其原始原型和通訊端操作/回呼，從用於與此對等體通訊的通訊端分離。在 TCP 的情況下，當對等體位於發行清單中時，使用者空間可能會決定關閉通訊端。這會導致並行執行：
    tcp_close（sk） __tcp_close（sk） sock_orphan（sk） sk_set_socket（sk， NULL） 最後一個函式呼叫會將 sk->sk_socket 設定為 NULL。當釋放常式恢復時，ovpn_tcp_socket_detach（） 將嘗試取消參照 sk->sk_socket 以還原其原始操作成員。此作業會因為 sk->sk_socket 為 NULL 而當機。透過在 sk->sk_callback_lock 下自動測試和存取 sk->sk_socket來修正此爭用情形。（CVE-2026-45918）

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

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

  - systeminformation 是用於 node.js 的系統和作業系統資訊庫。在 5.30.8 之前的版本中，「wifiNetworks()」函式中的命令插入弱點允許攻擊者透過重試程式碼路徑中未清理的網路介面參數執行任意作業系統命令。在「lib/wifi.js」中，「wifiNetworks()」函式會在初始呼叫時清理「iface」參數 (第 437 行)。然而，當初始掃描傳回空結果時，「setTimeout」重試 (行 440-441) 會呼叫「getWifiNetworkListIw(iface)」，其中包含**原始未清理**「iface」值，該值會直接傳遞給「execSync('iwlist ${iface} scan')」。任何將使用者控制的輸入傳遞給「si.wifiNetworks()」的應用程式都容易受到攻擊，攻擊者可透過 Node.js 處理程序的權限執行任意命令。5.30.8 版已修正此問題。 (CVE-2026-26280)

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

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

  - apparmor：避免 aa_get_buffer 中的 per-cpu 保留反向溢位 當 aa_get_buffer（） 從 per-cpu 清單中提取時，它會無條件地遞減快取>保留。如果保留達到 0，而計數仍為非零，則不帶正負號的遞減會換行為 UINT_MAX。這會在很長一段時間內保持非零，因此 aa_put_buffer（） 永遠不會將緩衝區傳回全域清單，這可能會使其他 CPU 飢餓並強制重複 kmalloc（aa_g_path_max） 分配。保護遞減，這樣就不會下溢。（CVE-2026-45884）

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

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

  - cgroup： 延遲 css percpu_ref rmdir 終止，直到 cgroup 被移除 回到 v7.0 的一連串提交重新設計了 rmdir，以滿足控制器不變量，即當任務仍在 cgroup 中執行核心端工作時，子系統的 ->css_offline（） 不得執行。[1] d245698d727a （cgroup：將任務 cgroup 解除連結推遲到任務完成切換之後） [2] a72f73c4dd9b （cgroup：不要在 cgroup 中暴露失效任務） [3] 1b164b876c36 （cgroup：等待垂死任務離開 rmdir） [4] 4c56a8ac6869 （cgroup：
    修正 cgroup_drain_dying（） 測試錯誤條件） [5] 13e786b64bd3 （cgroup：從 rmdir 上下文增量 nr_dying_subsys_*） [1] 將任務 cset unlink 從 do_exit（） 移至 finish_task_switch（），因此只有在任務完全停止排程後，任務的 cset 連結才會刪除。這使得 exit_signals（） 之後的任務在 cset->tasks 上徘徊，直到它們最終的上下文切換，這導致了一系列問題，因為使用者空間在 rmdir 之後期望看到的內容與核心需要等待的內容不同。[2]-[5] 試圖彌合這種分歧：[2] 從 cgroup.procs 過濾了現有任務;[3] 讓 rmdir（2） 為他們睡TASK_UNINTERRUPTIBLE;[4] 修正了等待的條件;[5] 使 nr_dying_subsys_* 同步可見。[3] 中的 cgroup_drain_dying（） 等待結果是一條死胡同。當 rmdir 呼叫者也是固定 pidns 拆卸的殭屍的收割者時 （例如，主機 PID 1 systemd 收割在相同拆卸期間重新父級的孤立 pid），rmdir 區塊在等待這些 pid 釋放的TASK_UNINTERRUPTIBLE中，pid 無法釋放，因為 PID 1 是收割者並且它卡在 rmdir 中， 以及系統 A-A 鎖死。沒有內部鎖定順序會破壞這一點;等待本身就是錯誤。然而，驅動原始重新排序的 css 終止端可以完全非同步：->css_offline（） 已經是非同步的，從由 percpu_ref_kill_and_confirm（） 驅動的 css_killed_work_fn（） 執行。修復方法是僅在所有任務離開 cgroup 後才啟動該鏈。一旦 cgroup.procs 和 friends 為空，rmdir 的使用者可見端就會返回，而 ->css_offline（） 僅在 cgroup 完全清空後仍會執行。由原始重現器（pidns teardown + zombie reaper，在 vng 下運行）驗證，該重現懸掛原版並在這裡成功，並通過 [2]、[3]、[4]、[5] 的每次提交確定性重現進行驗證，其啟動參數會加寬 （） 窗口， post-exit_signals以便每個狀態都可以可靠地訪問。除此之外，還有一些壓力測試。cgroup_apply_control_disable（） 具有與先前存在的爭用相同的形狀：當控制器透過 subtree_control 停用時，kill_css（） 同步運行，而 exit_signals（） 之後的任務仍然可以連結到 cgroup 的 cset，並且 ->css_offline（） 可以在它們耗盡之前觸發。此修補程式會保留該呼叫網站現有的同步行為 （kill_css_sync（） + kill_css_finish（） 背對背），而後續修補程式會使用 per-css 觸發程序延遲 kill_css_finish（）。這似乎是正確的方法，我不認為它有問題。這些更改有些侵入性，但並不過分，因此反向移植到 -stable 應該沒問題。如果確實有問題，後備措施是還原整個鏈 （[1]-[5]） 並在開發分支中重做。v2：將 cgrp 固定在延遲的銷毀工作中，並在 queue_work（） 周圍使用顯式 cgroup_get（）/cgroup_put（） 和 work_fn。v1 實際上並沒有被破壞（cgroup_offline_wq排序 + cgroup_task_dead（） 中的queue_work順序保存了它），但顯式 ref 消除了對那些非明顯不變量的依賴。另請注意描述中預先存在的 cgroup_apply_control_disable（） 爭用;後續行動將在那裡推遲 kill_css_finish（）。
    (CVE-2026-46223)

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

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

  - drm/amdgpu：修正 amdgpu_ras_init（） 中的記憶體洩漏 當 amdgpu_ras_init（） 中的 amdgpu_nbio_ras_sw_init（） 失敗時，函數直接返回而不釋放分配的 con 結構，導致記憶體洩漏。在傳回錯誤代碼之前，跳到release_con標籤以正確清理分配的記憶體來解決此問題。僅經過編譯測試。使用原型靜態分析工具和程式碼檢閱發現問題。（CVE-2026-45976）

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

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

  - mm/damon/core：修正 damos_walk（） 與 kdamond_fn（） 退出爭用 當 kdamond_fn（） 主迴圈完成後，函數會取消剩餘的 damos_walk（） 請求並取消設定 damon_ctx->kdamond，以便 API 呼叫者和 API 函數本身可以顯示上下文已終止。damos_walk（） 會先將呼叫端的要求新增至佇列。之後，它會顯示damon_ctx的 kdamond 是否仍在執行 （已設定 damon_ctx->kdamond）。只有當 kdamond 正在執行時，damos_walk（） 才會開始等待 kdamond 處理新新增的請求。不過，damos_walk（） 請求註冊和 damon_ctx->kdamond 取消設定受到不同互斥的保護。因此，damos_walk（） 可能會在未設定 damon_ctx->kdamond 的情況下爭用，並導致鎖死。例如，假設 kdamond 成功完成了 damow_walk（） 請求的取消。
    緊接著，系統會呼叫 damos_walk（） 來顯示上下文。它會註冊新要求，並顯示內容仍在執行，因為 damon_ctx->kdamond 未設定尚未完成。因此，damos_walk（） 呼叫端開始等待請求的處理。不過，kdamond 已在終止步驟中，因此永遠不會處理新要求。因此，damos_walk（） 呼叫端執行緒會無限等候。透過引入另一個damon_ctx欄位（即 walk_control_obsolete）來解決此問題。它受到 damon_ctx->walk_control_lock 保護，可保護 damos_walk（） 要求註冊。在讓 damon_start（） 傳回之前在 kdamond_fn（） 中初始化（取消設定），並在執行剩餘 damos_walk（） 請求的取消之前設定它。damos_walk（） 讀取鎖定下的過時欄位，避免新增請求。在此變更之後，只會註冊保證處理或取消的要求。因此，不再需要註冊後 DAMON 內容終止檢查。一起移除。該問題由 sashiko [1] 發現。（CVE-2026-46008）

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

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

  - powerpc/xive：修正由錯誤的 chip_data 查詢引起的 kmemleak kmemleak 報告以下記憶體洩漏： 未參照的物件0xc0000002a7fbc640（大小 64）：comm kworker/8:1、pid 540、jiffies 4294937872 hex 轉儲（前 32 個位元組）：01 00 00 00 00 00 00 00 00 09 04 00 04 00 00 ................00 00 a7 81 00 00 0a c0 00 00 08 04 00 04 00 00 ................回溯 （crc 177d48f6）：
    __kmalloc_cache_noprof+0x520/0x730 xive_irq_alloc_data.constprop.0+0x40/0xe0 xive_irq_domain_alloc+0xd0/0x1b0 irq_domain_alloc_irqs_parent+0x44/0x6c pseries_irq_domain_alloc+0x1cc/0x354 irq_domain_alloc_irqs_parent+0x44/0x6c msi_domain_alloc+0xb0/0x220 irq_domain_alloc_irqs_locked+0x138/0x4d0 __irq_domain_alloc_irqs+0x8c/0xfc
    __msi_domain_alloc_irqs+0x214/0x4d8 msi_domain_alloc_irqs_all_locked+0x70/0xf8 pci_msi_setup_msi_irqs+0x60/0x78 __pci_enable_msix_range+0x54c/0x98c pci_alloc_irq_vectors_affinity+0x16c/0x1d4 nvme_pci_enable+0xac/0x9c0 [nvme] nvme_probe+0x340/0x764 [nvme] 為 NVMe 裝置配置 MSI-X 向量時會發生這種情況。在配置期間，XIVE 程式碼會建立結構xive_irq_data，並將它儲存在 irq_data->chip_data 中。稍後釋放 MSI-X irqdomain 時，xive_irq_free_data（） 負責擷取此結構並釋放它。但是，在提交 cc0cc23babc9 （powerpc/xive：從子中斷控制器驅動程式中解開 xive） 之後，xive_irq_free_data（） 會使用 irq_get_chip_data（） 擷取chip_data，這會透過子網域查詢資料。這是不正確的，因為 XIVE 特定的 irq 資料與 XIVE （母項） 網域相關聯。結果，查詢失敗，並且分配的結構xive_irq_data永遠不會被釋放，從而導致上面顯示的 kmemleak 報告。透過使用 irq_domain_get_irq_data（） 從正確的網域擷取irq_data，然後透過 irq_data_get_irq_chip_data（） 存取chip_data來解決此問題。（CVE-2026-46141）

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

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

  - wifi： mac80211：從 fast-RX rx_result ieee80211_invoke_fast_rx（） 刪除偏離的「靜態」被記錄為對並行 RX 是安全的，但其每次調用rx_result被宣告為靜態。然後，並發調用者共享一個實例，並且可以在 ieee80211_rx_mesh_data（） 和 res 上的開關之間覆蓋彼此的結果。
    這可能會使 ieee80211_rx_mesh_data（） 排入佇列或消耗的封包落入 ieee80211_rx_8023（），或使應該繼續排入佇列的封包返回。將 res 設為自動變數，讓每個叫用保留自己的結果。（CVE-2026-46152）

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

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

  - vfio/cdx：使用每個裝置互斥序列化VFIO_DEVICE_SET_IRQS vfio_cdx_set_msi_trigger（） 讀取 vdev->config_msi 並根據其值在 vdev->cdx_irqs 陣列上運作，但不會針對並行VFIO_DEVICE_SET_IRQS ioctl 進行序列化。兩個調用方可以爭用，這樣一個調用方會按照設定觀察config_msi，而另一個調用方則清除它並通過 vfio_cdx_msi_disable（） 釋放cdx_irqs，從而導致 cdx_irqs 陣列的釋放後使用。新增cdx_irqs_lock互斥以結構vfio_cdx_device並在 vfio_cdx_set_msi_trigger（） 中取得它，這是所有更新到 config_msi、cdx_irqs 和 msi_count 流程的單一阻塞點，涵蓋 ioctl 路徑和關閉裝置清理路徑。這會將config_msi測試與後續的啟用、停用或觸發作業保持不可部分完成。作為此變更的一部分，從 vfio_cdx_irqs_cleanup（） 刪除預先呼叫 ！cdx_irqs 測試：它提供的最佳化與 vfio_cdx_msi_disable（） 中的 ！config_msi 提前返回是多餘的，並且保留測試將是對新鎖旨在保護的狀態的不同步讀取。（CVE-2026-46036）

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

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

  - remoteproc：xlnx：只有在緩衝 IPI 時才存取緩衝區資訊 在接收回呼中檢查訊息是否為 NULL，以防止因 NULL 指標解除參照而損毀的可能性。（CVE-2026-46016）

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

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

  - crypto：starfive - 修正 starfive_aes_aead_do_one_req（） 中的記憶體洩漏 starfive_aes_aead_do_one_req（） 函數使用 kzalloc（） 配置 rctx->adata，但如果 sg_copy_to_buffer（） 或 starfive_aes_hw_init（） 失敗，則無法釋放它，從而導致記憶體洩漏。由於 rctx->adata 在write_adata作業之後會無條件釋放，因此也藉由釋放這些早期錯誤路徑中的配置來確保一致的清除。僅經過編譯測試。使用原型靜態分析工具和程式碼檢閱發現問題。
    (CVE-2026-45950)

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

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

  - 已解決 Linux 核心中的下列弱點：io_uring/zcrx: fix user_struct uaf io_free_rbuf_ring() usees a struct user_struct, which io_zcrx_ifq_free() puts it down before destroying the ring. (CVE-2026-45995)

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

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

  - Dolibarr ERP/CRM v.22.0.0 至 v.22.0.4 和 v.24.0.0-alpha 中的一個問題允許遠端攻擊者透過 htdocs/core/actions_addupdatedelete.inc.php （CVE-2026-37711） 執行任意程式碼

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

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

  - Ubuntu Linux 6.8， 7.17 並 7.0 包含 AppArmor SAUCE 修補程式，在某些情況下，可以在通知處理程式碼中使用未初始化的變數。此錯誤可由無特權的本機使用者觸發，並可能導致 AppArmor 通知回應快取不正確。（CVE-2026-47330）

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

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

  - 在早於 5.2.15 版的 Django 5.2 和早於 6.0.6 版的 Django 6.0 中發現一個問題。
    Django 中的 'django.middleware.cache.UpdateCacheMiddleware' 不會將 'Authorization' 添加到帶有該標頭的請求的 'Vary' 回應標頭中，而沒有 'Cache-Control： public'，這允許遠端攻擊者透過對同一 URL 的未經身份驗證的請求讀取私有快取的回應。先前，不支援的 Django 系列（例如 5.0.x、 和 4.1.x3.2.x）沒有被評估，也可能受到影響。
    Django 在此感謝 Shai Berger 報告此問題。（CVE-2026-35193）

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

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

  - af_unix：修正 unix_stream_connect（） 中 newsk 的 memleak。當 unix_stream_connect（） 中的 prepare_peercred（） 失敗時，newsk 不會呼叫 unix_release_sock（），記憶體就會洩漏。讓我們在 unix_create1（） 之前移動 prepare_peercred（）。（CVE-2026-45887）

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

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

  - fs/ntfs3：修正 DeleteIndexEntryRoot 中的 slab-out-of-bounds 讀取 在 'do_action' 函式的 'DeleteIndexEntryRoot' 情況下，系統會從記錄檔中擷取項目大小 （'esize'），而無需進行充分的邊界檢查。具體來說，程式碼使用以下命令計算條目 （'e2'） 的結尾： e2 = Add2Ptr（e1， esize）;然後，它使用 'PtrOffset（e2， ...）' 計算 memmove 的大小，這會從緩衝區限制中減去結束指標。如果 'esize' 惡意較大，則 'e2' 會超出使用的緩衝區大小。這會導致負偏移，當轉換為 memmove 的size_t時，會解譯為大量無正負號整數，導致堆積緩衝區溢位。此提交會新增檢查，以確保在執行記憶體作業之前，項目大小 （'esize'） 嚴格符合索引標頭的剩餘已用空間。（CVE-2026-45935）

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

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

  - power： supply： pm8916_bms_vm：修正 power_supply_changed（） 中的釋放後使用 'devm_' 變體來請求 IRQ _before_ 用於配置/註冊 'power_supply' 句柄的 'devm_' 變體，意味著 'power_supply' 句柄將在中斷處理常式之前取消配置/取消註冊（因為 'devm_' 自然地以相反的分配順序解除配置）。這表示在移除期間，會發生爭用情形，即中斷可能會在 'power_supply' 控制碼被釋放之後觸發，*但是* 就在 IRQ 處理常式的對應取消註冊執行之前。這將導致 IRQ 處理常式呼叫具有釋放的 'power_supply' 句柄的 'power_supply_changed（）'。這通常會使系統崩潰或以其他方式無聲地損壞記憶體... 請注意，在「probe（）」期間也可能發生類似的情況;在註冊 'power_supply' 控制碼之前_中斷觸發的可能性。這將導致在「power_supply_changed（）」中使用「power_supply」句柄*未初始化*的惡劣情況。透過確保在註冊 'power_supply' 控制碼之後 _ 請求 IRQ，來修正此 racy 釋放後使用。（CVE-2026-45882）

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

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

  - drm/amdgpu：在 amdgpu_gmc_get_nps_memranges（） 中使用 kvfree 而不是 kfree amdgpu_discovery_get_nps_info（） 會在內部使用 kvcalloc（） 為範圍配置記憶體，這可能會使用 vmalloc（） 進行大量配置。
    使用 kfree（） 釋放 vmalloc 記憶體會導致記憶體損毀。使用 kvfree（） 安全地處理 kmalloc 和 vmalloc 分配。僅經過編譯測試。使用原型靜態分析工具和程式碼檢閱發現問題。（CVE-2026-45853）

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

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

  - RDMA/mana：驗證rx_hash_key_len Sashiko 指出rx_hash_key_len來自 uAPI 結構，並盲目地傳遞給 memcpy，允許使用者空間丟棄核心記憶體。邊界檢查它，這樣 memcpy 就不會溢位。（CVE-2026-46145）

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

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

  - 已解決 Linux 核心中的下列弱點：mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that unconditionally succeeds even when the lock is already held. As a result, alloc_frozen_pages_nolock() called from NMI context can re-enter rmqueue() and acquire the zone lock that the interrupted context is already holding, corrupting the freelists. With CONFIG_DEBUG_SPINLOCK on UP, the following BUG is triggered with the slub_kunit test module: BUG: spinlock trylock failure on UP on CPU#0, kunit_try_catch/243 [...] Call Trace: <NMI> dump_stack_lvl+0x3f/0x60 do_raw_spin_trylock+0x41/0x50
    _raw_spin_trylock+0x24/0x50 rmqueue.isra.0+0x2a9/0xa70 get_page_from_freelist+0xeb/0x450 alloc_frozen_pages_nolock_noprof+0x111/0x1e0 allocate_slab+0x42a/0x500 ___slab_alloc+0xa7/0x4c0 kmalloc_nolock_noprof+0x164/0x310 [...] </NMI> Fix this by returning NULL early when invoked from NMI on a UP kernel. (CVE-2026-46035)

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

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

  - hwmon：（powerz） 避免 DMA 緩衝區的快取行共用 視架構而定，傳輸緩衝區可能會與下列互斥共用快取行。由於緩衝區可能用於 DMA，因此這是有問題的。
    使用高階 DMA 協助程式來確保快取行共用無法發生。還要刪除評論，因為助手已經足夠文檔了。
    https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org (CVE-2026-46007)

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

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

  - ovpn：修正 ovpn_net_xmit 中可能的釋放後使用 在 ovpn_net_xmit 中建置 skb_list 時，如果原始 skb 是共用的，skb_share_check 將釋放它。目前的實作會繼續使用過時的 skb 指標進行後續作業： - 對等查詢， - skb_dst_drop （即使skb_gso_segment產生的所有區段都會附加 dst）， - ovpn_peer_stats_increment_tx。透過在分割之前移動對等查詢和skb_dst_drop來修正此問題，以便原始 skb 在使用時仍然有效。
    如果所有區段都失敗skb_share_check且清單最終為空，請提前返回。也切換ovpn_peer_stats_increment_tx以使用 skb_list.next;下一個補丁修復了統計邏輯。（CVE-2026-45929）

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

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

  - Ubuntu Linux 6.8， 6.17 並 7.0 包含 SAUCE 修補程式，在處理對 AppArmor 通知的大回應時存在記憶體洩漏。此錯誤可由無特權的本機使用者觸發。記憶體洩漏可能會導致資源耗盡。（CVE-2026-47326）

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

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

  - EDAC/versalnet： 修正裝置名稱記憶體洩漏 透過 init_one_mc（） 中的 kzalloc（） 配置的裝置名稱會指派給 dev->init_name，但在正常移除路徑上永遠不會釋放。device_register（） 會複製init_name，然後將 dev->init_name 設為 NULL，因此裝置無法連線名稱指標。從而洩漏記憶體。使用堆疊本機 char 陣列，而不是使用 kzalloc（） 作為名稱。（CVE-2026-46221）

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

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

  - crypto：inside-secure/eip93 - 取消註冊 僅可用演算法 EIP93 具有選項暫存器。此暫存器指示在晶片中實作哪些加密演算法。支援的演算法是在此基礎上註冊的。在相同的基礎上取消註冊演算法。目前，所有演算法都已取消註冊，即使是硬體不支援的演算法也是如此。這會導致在沒有在芯片中實現所有選項的平台上出現恐慌。（CVE-2026-45854）

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

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

  - media：iris：修正 MBPF 檢查期間的fmt_src釋放後使用 在並行測試期間，多個執行個體可以並行執行，每個執行個體使用自己的 inst->lock，而 core->lock 則保護作用中執行個體的清單。發生爭用是因為這些鎖涵蓋不同的範圍，inst->lock 僅保護單個實例的內部，而每幀宏塊數 （MBPF） 檢查器在 core->lock 下遍歷核心列表並讀取 fmt_src->width 和 fmt_src->height 等字段。同時，當實例仍存在於核心清單中時，iris_close（） 可能會釋放 fmt_src 並在 inst->lock 下fmt_dst。這允許 MBPF 檢查程式仍在反覆運算核心清單，到達其fmt_src已由另一個執行緒釋放的實例，並最終取消參照懸置指標，導致釋放後使用。發生這種情況的原因是 MBPF 檢查程式假設核心清單中的任何執行個體都完全有效，但釋放fmt_src和fmt_dst而不從核心清單中移除執行個體是不正確的。正確的順序是延遲釋放fmt_src和fmt_dst，直到執行個體已從核心清單中移除，且核心鎖定下的所有拆卸都已完成，以確保在 MBPF 檢查期間不會公開任何懸置指標。（CVE-2026-46210）

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

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

  - 在早於 5.2.15 版的 Django 5.2 和早於 6.0.6 版的 Django 6.0 中發現一個問題。
    Django 中的 'django.utils.cache.has_vary_header（）' 在比較之前不會從 'Vary' 回應標頭值中去除前導或尾隨空格，這允許遠端攻擊者透過對回應包含空格填充 Vary 標頭值的 URL 的請求來讀取快取的回應。先前，不支援的 Django 系列（例如 5.0.x、 和 4.1.x3.2.x）沒有被評估，也可能受到影響。Django 在此感謝 Navid Rezazadeh 報告此問題。（CVE-2026-48587）

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

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

  - greybus： gb-beagleplay：修正 hdlc_tx_frames（） 中原子上下文中的睡眠 hdlc_append（） 呼叫 usleep_range（） 以等待循環緩衝區空間，但它是透過 hdlc_tx_frames（） -> hdlc_append_tx_frame（）/hdlc_append_tx_u8（）/etc 持有的 tx_producer_lock （自調鎖） 呼叫的。持有微調鎖時休眠是非法的，可能會觸發 BUG：不可部分完成時的排程。在取得微調鎖定之前，將緩衝區空間等待移出 hdlc_append（） 並移至 hdlc_tx_frames（） 來修正此問題。新流程： 1. 預先計算最壞情況下的編碼幀長度。2. 在鎖定之外等待 （睡眠），直到有足夠的空間可用，然後啟動 TX 消費者工作以耗盡緩衝區。3. 取得自旋鎖，重新驗證空間，並自動寫入整個框架。這可確保睡眠只會在沒有任何鎖定的情況下發生，而且框架要麼完全排入佇列，要麼根本不寫入。此錯誤是由 CodeQL 靜態分析工具 （程序間原子睡眠查詢） 和我的程式碼檢閱發現的。（CVE-2026-46041）

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

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

  - hwmon：（powerz） 修正訊號中斷上缺少的 usb_kill_urb（），中斷時 wait_for_completion_interruptible_timeout（） 會傳回 -ERESTARTSYS。這需要中止 URB 並傳回錯誤。尚未從裝置收到任何資料，因此從傳輸緩衝區讀取的任何資料都是無效的。原始程式碼測試 ！ret，它只捕獲逾時情況 （0）。在訊號傳遞 （-ERESTARTSYS） 時，！ret 為 false，因此函式會跳過 usb_kill_urb（） 並從未填入的傳輸緩衝區中讀取。透過將傳回值擷取為 long （符合函式傳回類型），並使用單獨的檢查來處理訊號 （負） 和逾時 （零） 案例，這兩個檢查都會在傳回之前呼叫 usb_kill_urb（） 來修正。（CVE-2026-46073）

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

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

  - accel/amdxdna：跨 iommu_sva_unbind_device（） 保留 mm 結構 某些測試會觸發 iommu_sva_unbind_device（） 中的損毀，這是因為在釋放相關聯的 mm 結構後存取 iommu_mm。在成功綁定裝置之後，明確參照 mm 結構，只有在裝置解除綁定之後才釋放它，藉此修正此問題。這可確保 mm 在整個 SVA 綁定/解除綁定存留期內保持有效。（CVE-2026-45931）

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

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

  - Ubuntu Linux 6.8， 6.17 並 7.0 包含 SAUCE 修補程式，在處理 AF_INET/AF_INET6 通訊端調解時可能具有 NULL 指標解除參照。此錯誤可由無特權的本機使用者觸發。
    這可能會導致核心 oops。（CVE-2026-47337）

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

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

  - mtd： parsers： 修正 mtd_parser_tplink_safeloader_parse（） 中的記憶體洩漏 函數 mtd_parser_tplink_safeloader_parse（） 透過 mtd_parser_tplink_safeloader_read_table（） 分配 buf。如果迴圈內 parts[idx].name 的分配失敗，程式碼會跳到err_free標籤而不釋放 buf，從而導致記憶體洩漏。透過釋放err_free標籤中的臨時緩衝區 buf 來修正此問題。僅經過編譯測試。使用原型靜態分析工具和程式碼檢閱發現問題。（CVE-2026-45921）

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

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

  - media：rockchip：rkcif：將缺少的 MUST_CONNECT 旗標新增至打擊板 打擊板會遺漏檢查已連接的裝置，當啟用串流時，這些裝置可能會發生 null 解除參照。無法處理虛擬位址 0000000000000020 PC 上的核心 NULL 指標解除參照：rkcif_interface_enable_streams+0x48/0xf0 lr：
    rkcif_interface_enable_streams+0x44/0xf0 呼叫追蹤：rkcif_interface_enable_streams+0x48/0xf0 v4l2_subdev_enable_streams+0x26c/0x3f0 rkcif_stream_start_streaming+0x140/0x278 vb2_start_streaming+0x74/0x188 vb2_core_streamon+0xe0/0x1d8 vb2_ioctl_streamon+0x60/0xa8 v4l_streamon+0x2c/0x40 __video_do_ioctl+0x34c/0x400 video_usercopy+0x2d0/0x800 video_ioctl2+0x20/0x60 v4l2_ioctl+0x48/0x78 （CVE-2026-46222）

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

ID	名稱	嚴重性
318566	Linux Distros 未修補弱點：CVE-2026-49942	high
318565	Linux Distros 未修補弱點：CVE-2026-49941	high
318564	Linux Distros 未修補弱點：CVE-2026-46252	medium
318563	Linux Distros 未修補弱點：CVE-2026-46254	medium
318562	Linux Distros 未修補弱點：CVE-2026-45702	medium
318561	Linux Distros 未修補弱點：CVE-2026-46267	high
318560	Linux Distros 未修補弱點：CVE-2026-46259	high
318552	Linux Distros 未修補弱點：CVE-2026-40290	high
318551	Linux Distros 未修補弱點：CVE-2026-6657	high
318550	Linux Distros 未修補弱點：CVE-2025-71313	medium
318549	Linux Distros 未修補弱點：CVE-2026-44546	medium
318548	Linux Distros 未修補弱點：CVE-2026-3276	medium
318547	Linux Distros 未修補弱點：CVE-2026-41283	critical
318546	Linux Distros 未修補弱點：CVE-2026-44545	high
318545	Linux Distros 未修補弱點：CVE-2026-48501	critical
318544	Linux Distros 未修補弱點：CVE-2026-45939	medium
318543	Linux Distros 未修補弱點：CVE-2026-45918	medium
318542	Linux Distros 未修補弱點：CVE-2026-26280	high
318541	Linux Distros 未修補弱點：CVE-2026-45884	medium
318540	Linux Distros 未修補弱點：CVE-2026-46223	medium
318539	Linux Distros 未修補弱點：CVE-2026-45976	medium
318538	Linux Distros 未修補弱點：CVE-2026-46008	medium
318537	Linux Distros 未修補弱點：CVE-2026-46141	medium
318536	Linux Distros 未修補弱點：CVE-2026-46152	high
318535	Linux Distros 未修補弱點：CVE-2026-46036	high
318534	Linux Distros 未修補弱點：CVE-2026-46016	medium
318533	Linux Distros 未修補弱點：CVE-2026-45950	medium
318532	Linux Distros 未修補弱點：CVE-2026-45995	high
318531	Linux Distros 未修補弱點：CVE-2026-37711	high
318530	Linux Distros 未修補弱點：CVE-2026-47330	low
318529	Linux Distros 未修補弱點：CVE-2026-35193	low
318527	Linux Distros 未修補弱點：CVE-2026-45887	medium
318526	Linux Distros 未修補弱點：CVE-2026-45935	high
318525	Linux Distros 未修補弱點：CVE-2026-45882	high
318524	Linux Distros 未修補弱點：CVE-2026-45853	high
318523	Linux Distros 未修補弱點：CVE-2026-46145	high
318522	Linux Distros 未修補弱點：CVE-2026-46035	medium
318521	Linux Distros 未修補弱點：CVE-2026-46007	medium
318520	Linux Distros 未修補弱點：CVE-2026-45929	high
318519	Linux Distros 未修補弱點：CVE-2026-47326	medium
318518	Linux Distros 未修補弱點：CVE-2026-46221	medium
318517	Linux Distros 未修補弱點：CVE-2026-45854	medium
318516	Linux Distros 未修補弱點：CVE-2026-46210	high
318515	Linux Distros 未修補弱點：CVE-2026-48587	low
318514	Linux Distros 未修補弱點：CVE-2026-46041	medium
318513	Linux Distros 未修補弱點：CVE-2026-46073	medium
318512	Linux Distros 未修補弱點：CVE-2026-45931	high
318511	Linux Distros 未修補弱點：CVE-2026-47337	low
318510	Linux Distros 未修補弱點：CVE-2026-45921	medium
318509	Linux Distros 未修補弱點：CVE-2026-46222	medium

偵測

Nessus 的 Misc. 系列

high

high

medium

medium

medium

high

high

high

high

medium

medium

medium

critical

high

critical

medium

medium

high

medium

medium

medium

medium

medium

high

high

medium

medium

high

high

low

low

medium

high

high

high

high

medium

medium

high

medium

medium

medium

high

low

medium

medium

high

low

medium

medium