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

  - fs： afs：還原 mmap_prepare（） 變更 部分還原提交 9d5403b1036c （fs：將大多數其他 generic_file_*mmap（） 使用者轉換為 .mmap_prepare（））。這是因為 .mmap 叫用會建立參照計數，但在呼叫之後可能會發生合併或配置失敗的點呼叫 .mmap_prepare，這會洩漏參照計數增量。在這種情況下，正在添加允許使用 .mmap_prepare 的功能，但在此期間，我們需要修復此問題。（CVE-2026-46100）

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

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

  - 已解決 Linux 核心中的下列弱點：ALSA: caiaq: fix usb_dev refcount leak on probe failure create_card() takes a reference on the USB device with usb_get_dev() and stores the matching usb_put_dev() in card_free(), which is installed as the snd_card's ->private_free destructor.
    However, ->private_free is only assigned near the end of init_card(), after several failure points (usb_set_interface(), EP type checks, usb_submit_urb(), the EP1_CMD_GET_DEVICE_INFO exchange, and its timeout). When any of those fail, init_card() returns an error to snd_probe(), which calls snd_card_free(card). Because ->private_free is still NULL, card_free() never runs, the usb_get_dev() reference is not dropped, and the struct usb_device leaks along with its descriptor allocations and device_private. syzbot reproduces this with a malformed UAC3 device whose only valid altsetting is 0;
    init_card()'s usb_set_interface(usb_dev, 0, 1) call fails with -EIO and triggers the leak. Move the
    ->private_free assignment into create_card(), immediately after usb_get_dev(), so that every error path reaching snd_card_free() balances the reference. card_free()'s callees (snd_usb_caiaq_input_free, free_urbs, kfree) already tolerate the partially-initialized state because the chip private area is zero-initialized by snd_card_new(). (CVE-2026-46048)

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

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

  - HID： appletb-kbd：修正 inactivity-timer 清理路徑中的 UAF 提交 38224c472a03 （HID： appletb-kbd：修正 appletb_kbd_probe 中的 slab 釋放後使用錯誤） 在探查close_hw錯誤路徑和 appletb_kbd_remove（） 中新增了 timer_delete_sync（&kbd->inactivity_timer），但它的連接方式使得在驅動程式拆卸期間可以透過兩個不同的視窗存取閒置計時器。視窗 A -- timer_delete_sync（） 之前的 put_device（）：put_device（&kbd->backlight_dev->dev）;timer_delete_sync（&kbd->inactivity_timer）;inactivity_timer softirq 讀取 kbd->backlight_dev 並呼叫 backlight_device_set_brightness（） -> mutex_lock（&ops_lock）。如果並行hid_appletb_bl解除綁定刪除了這兩個調用之間的最後一個 devm 參照，則backlight_device將被釋放，並且 mutex_lock（） 會接觸釋放的記憶體。視窗 B -- hid_hw_stop（） 之前的背光清理： if （kbd->backlight_dev） { timer_delete_sync（...）; put_device（...）; } hid_hw_close（hdev）;hid_hw_stop（hdev）;即使在視窗 A 關閉之後，hid_hw_close（）/hid_hw_stop（） 仍會執行，因此來自 HID 核心的延遲 .event 回呼 （在真正的 Apple 硬體上完成） 可以在 timer_delete_sync（） 耗盡 softirq 之後，但在 put_device（） 刪除參照之前到達。該回呼到達 reset_inactivity_timer（），後者呼叫 mod_timer（） 並重新武裝計時器。然後，新重新武裝的計時器可以向即將釋放的backlight_device開火。兩個視窗都會產生相同的 KASAN slab-use-after-free： 錯誤： KASAN：__mutex_lock+0x1aab/0x21c0 中的 slab-use-after-free 由 task swapper/0/0 在 addr ffff88803ee9a108 讀取大小 8 呼叫追蹤： <IRQ> __mutex_lock backlight_device_set_brightness appletb_inactivity_timer call_timer_fn run_timer_softirq handle_softirqs 由任務 N 分配：
    devm_backlight_device_register appletb_bl_probe 由任務 M 釋放：（並行hid_appletb_bl解除綁定路徑） 透過在 appletb_kbd_remove（） 和探查close_hw錯誤路徑中重新執行拆卸，以立即關閉兩個視窗，以便 1） hid_hw_close（）/hid_hw_stop（） 在背光清理之前執行，保證沒有進一步的 .event 回呼可以觸發和重新布防計時器， 2） 在 if （kbd->backlight_dev） 區塊內，timer_delete_sync（） 在 put_device（） 之前運行，因此在刪除最終參照之前，softirq 會被排空。（CVE-2026-46213）

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

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

  - systeminformation 是用於 node.js 的系統和作業系統資訊庫。在 Linux 上，從 4.17.0 到 5.31.5 版，當作用中的 NetworkManager 連線設定檔名稱包含 shell 中繼字元時，systeminformation 很容易受到 networkInterfaces() 中命令插入弱點的影響。易受攻擊的值是在內部獲取的，來源於實際 nmcli 裝置狀態輸出。在 shell 命令中使用網路介面名稱之前，程式庫會先對其進行清理，但不會將對等的清理套用至剖析的 NetworkManager 連線設定檔名稱。然後，未清理的 connectionName 會插入透過 execSync() 執行的三個 shell 命令字串。此弱點已在 5.31.6 中修正。(CVE-2026-44724)

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

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

  - mm/damon/stat：修正 damon_stat_start（） 中 damon_start（） 失敗時的記憶體洩漏 當 damon_start（） 失敗時，破壞 DAMON 上下文並重設全域指標。否則，damon_stat_build_ctx（） 配置的上下文會洩漏，並且過時的damon_stat_context指標將在下次啟用嘗試時被覆寫，從而使舊的分配永久無法訪問。（CVE-2026-46087）

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

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

  - 已解決 Linux 核心中的下列弱點：bpf: Return proper address for non-zero offsets in insn array The map_direct_value_addr() function of the instruction array map incorrectly adds offset to the resulting address. This is a bug, because later the resolve_pseudo_ldimm64() function adds the offset. Fix it. Corresponding selftests are added in a consequent commit. (CVE-2026-45967)

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

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

  - MCTP I2C：初始化事件處理常式讀取位元組 設定 MCTP-I2C 裝置的 I2C 讀取的0xff值。
    否則讀取將從 i2c 匯流排驅動程式傳回 val。對於 i2c-aspeed 和 i2c-npcm7xx，這是一個未初始化的堆疊 u8。使用 i2ctransfer -y 1 r10@0x34 測試，其中 0x34 是 mctp-i2c 執行個體，現在它會傳回所有0xff。（CVE-2026-45865）

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

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

  - selinux：在通訊端權限協助程式中使用 sk blob 存取子 SELinux 通訊端狀態位於複合 LSM 通訊端 blob 中。sock_has_perm（） 和 nlmsg_sock_has_extended_perms（） 目前會直接解除參照 sk->sk_security，這假設 SELinux 通訊端 blob 位於位移零。在堆疊組態中，此假設不成立。如果另一個 LSM 在 SELinux 之前配置通訊端 blob 儲存體，這些協助程式可能會讀取錯誤的 blob，並將無效的 SID 和類別值饋送至 AVC 檢查中。使用 selinux_sock（） 而不是直接存取 sk->sk_security。（CVE-2026-46104）

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

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

  - drm/amdgpu：修正 amdgpu_acpi_enumerate_xcc（） 中的記憶體洩漏 在 amdgpu_acpi_enumerate_xcc（） 中，如果 amdgpu_acpi_dev_init（） 傳回 -ENOMEM，則函數直接返回而不釋放分配的xcc_info，導致記憶體洩漏。確保在錯誤路徑中正確釋放xcc_info來修正此問題。僅經過編譯測試。使用原型靜態分析工具和程式碼檢閱發現問題。
    (CVE-2026-45947)

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

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

  - 已解決 Linux 核心中的下列弱點：slub: fix data loss and overflow in krealloc() Commit 2cd8231796b5 (mm/slub: allow to set node and align in k[v]realloc) introduced the ability to force a reallocation if the original object does not satisfy new alignment or NUMA node, even when the object is being shrunk. This introduced two bugs in the reallocation fallback path: 1. Data loss during NUMA migration: The jump to 'alloc_new' happens before 'ks' and 'orig_size' are initialized. As a result, the memcpy() in the 'alloc_new' block would copy 0 bytes into the new allocation. 2. Buffer overflow during shrinking: When shrinking an object while forcing a new alignment, 'new_size' is smaller than the old size. However, the memcpy() used the old size ('orig_size ?: ks'), leading to an out-of-bounds write. The same overflow bug exists in the kvrealloc() fallback path, where the old bucket size ksize(p) is copied into the new buffer without being bounded by the new size. A simple reproducer: // e.g.
    add to lkdtm as KREALLOC_SHRINK_OVERFLOW while (1) { void *p = kmalloc(128, GFP_KERNEL); p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); kfree(p); } demonstrates the issue:
    ================================================================== BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130 Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):
    memcpy_orig+0x68/0x130 krealloc_node_align_noprof+0x1c8/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64 allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago):
    krealloc_node_align_noprof+0x19c/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... ================================================================== Fix it by moving the old size calculation to the top of __do_krealloc() and bounding all copy lengths by the new allocation size. (CVE-2026-45990)

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

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

  - 已解決 Linux 核心中的下列弱點：drm: Set old handle to NULL before prime swap in change_handle There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths (CVE-2026-46215)

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

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

  - ice：修正 ice_sf_eth_activate（） 錯誤路徑中的雙重釋放 當 auxiliary_device_add（） 失敗時，ice_sf_eth_activate（） 跳轉至 aux_dev_uninit 並呼叫 auxiliary_device_uninit（&sf_dev->adev）。裝置釋放回呼 ice_sf_dev_release（） 會釋放sf_dev，但目前的錯誤路徑會流向 sf_dev_free，並再次呼叫 kfree（sf_dev），造成雙重釋放。保留 kfree（sf_dev） 作為 auxiliary_device_init（） 失敗路徑，但避免在 auxiliary_device_uninit（） 之後失敗為 sf_dev_free。（CVE-2026-46162）

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

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

  - Bluetooth： hci_event：修正 hci_le_create_big_complete_evt hci_le_create_big_complete_evt（） 中的 OOB 讀取和無限迴圈，使用 while 迴圈反覆運算 BIG 句柄的 BT_BOUND 連線，並在每次反覆運算時存取 ev->bis_handle[i++]。但是，在陣列存取之前，沒有檢查 i 是否保持在 ev->num_bis 內。當控制器傳送的 LE_Create_BIG_Complete 事件的 bis_handle 項目少於該 BIG 的 BT_BOUND 連線數，或 num_bis=0 時，迴圈會讀取超出有效 bis_handle[] flex 陣列的相鄰堆積記憶體。由於越界值通常會超過 HCI_CONN_HANDLE_MAX （0x0EFF），因此 hci_conn_set_handle（） 會拒絕這些值，且連線會保持BT_BOUND狀態。然後，hci_conn_hash_lookup_big_state（） 再次找到相同的連接，從而創建一個具有保留hci_dev_lock的無限循環。如果無法正確設定所有 BIS，請終止 BIG，以解決此問題。（CVE-2026-46138）

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

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

  - 電源：電源：bq256xx：修正 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-45902）

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

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

  - 輸入：edt-ft5x06 - 修正 debugfs 拆卸中的釋放後使用 提交 68743c500c6e （輸入：edt-ft5x06 - 使用 per-client debugfs 目錄） 移除了手動 debugfs 拆卸，依賴 I2C 核心來處理它。但是，這會建立一個視窗，在 edt_ft5x06_ts_teardown_debugfs（） 釋放 tsdata->raw_buffer 後，仍可存取 debugfs 檔案。若要防止釋放後使用，請使用裝置互斥保護釋放的raw_buffer，並將 raw_buffer 設為 NULL。debugfs 讀取函式已經檢查raw_buffer在同一互斥元件下是否為 NULL，因此這可以安全地避免釋放後使用。
    (CVE-2026-46097)

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

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

  - platform/chrome： cros_ec_typec：初始化 Thunderbolt 註冊 cros_typec_register_thunderbolt（） 中的互斥，未初始化「adata->lock」互斥。當稍後取得互斥時，這會導致 NULL 取消參照 （例如在 cros_typec_altmode_work（） 中）。初始化 cros_typec_register_thunderbolt（） 中的互斥以修正此問題。（CVE-2026-46134）

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

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

  - RDMA/mlx5：修正 mlx5_ib_dev_res_srq_init（） 中的錯誤路徑貫穿 mlx5_ib_dev_res_srq_init（） 配置兩個 SRQ s0 和 s1。當 s1 的 ib_create_srq（） 失敗時，錯誤分支會破壞 s0，但會失敗，並無條件地將釋放的 s0 和ERR_PTR s1 分配給 devr->s0 和 devr->s1。這會導致幾個問題：無鎖定快速路徑檢查 （devr->s1） 是否傳回 0;並將ERR_PTR視為已初始化;mlx5_ib_create_qp（ERR_PTR） 中的使用者透過 to_msrq（devr->s0）->msrq.srqn;mlx5_ib_dev_res_cleanup（） 取消參照 ERR_PTR 並在拆卸時雙重釋放 s0。透過在 s1 失敗路徑中新增相同的「goto 解鎖」來修復。（CVE-2026-46176）

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

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

  - 已解決 Linux 核心中的下列弱點：sched_ext: Read scx_root under scx_cgroup_ops_rwsem in cgroup setters scx_group_set_{weight,idle,bandwidth}() cache scx_root before acquiring scx_cgroup_ops_rwsem, so the pointer can be stale by the time the op runs. If the loaded scheduler is disabled and freed (via RCU work) and another is enabled between the naked load and the rwsem acquire, the reader sees scx_cgroup_enabled=true (the new scheduler's) but dereferences the freed one - UAF on SCX_HAS_OP(sch, ...) / SCX_CALL_OP(sch, ...). scx_cgroup_enabled is toggled only under scx_cgroup_ops_rwsem write (scx_cgroup_{init,exit}), so reading scx_root inside the rwsem read section correlates @sch with the enabled snapshot. (CVE-2026-46154)

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

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

  - smb/client：修正 smb2_compound_op（） 中的越界讀取 如果伺服器傳送截斷的回應但 OutputBufferLength 較大，並提前終止 EA 清單，則 check_wsl_eas（） 會傳回成功，而不驗證整個 OutputBufferLength 是否適合 iov_len。然後 smb2_compound_op（） 會執行：
    memcpy（idata->wsl.eas， data[0]， size[0]）;其中 size[0] 是 OutputBufferLength。如果iov_len小於 size[0]，memcpy 可以讀取超出rsp_iov配置的末尾，並洩漏相鄰的核心堆記憶體。
    (CVE-2026-46155)

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

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

  - VSOCK/virtio：針對非線性緩衝區修正 tap skb 中的空負載 對於非線性 skb，virtio_transport_build_skb（） 會透過 virtio_transport_copy_nonlinear_skb（） 將原始負載複製到新 skb 中，以傳送至 vsockmon tap 裝置。這會手動初始化iov_iter，但不會設定 iov_iter.count。由於iov_iter是零初始化的，因此複製長度為零，而且實際上不會將任何承載複製到監視器介面，因此資料未初始化。透過刪除線性與非線性分割並針對所有情況使用 skb_copy_datagram_iter（） 和 iov_iter_kvec（） 來解決此問題，就像 vhost-vsock 已經做的那樣。這會同時處理線性和非線性 skb，正確初始化iov_iter，並移除現在未使用的 virtio_transport_copy_nonlinear_skb（）。在觸摸這段程式碼的同時，我們也檢查一下 skb_copy_datagram_iter（） 的傳回值，即使它不太可能失敗。（CVE-2026-46207）

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

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

  - Ubuntu Linux 6.8 包含 AppArmor SAUCE 修補程式，這些修補程式在修改連結清單時無法取得鎖定。無特權的本機使用者可能會觸發爭用情形，進而導致釋放後使用 （UAF），理論上會導致任意程式碼執行。（CVE-2026-47331）

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

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

  - HID：playstation：新增 input_ff_create_memless 的遺漏檢查 ps_gamepad_create（） 函式在未驗證其傳回值的情況下呼叫 input_ff_create_memless（），這可能會導致觸發 FF 效果時出現不正確的行為或潛在的崩潰。新增 input_ff_create_memless（） 傳回值的檢查。（CVE-2026-45969）

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

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

  - 已解決 Linux 核心中的下列弱點：pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle() commit 6d3789d347a7 (papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()), changed the create handle to FD_PREPARE(), but it caused kernel null-ptr-deref because after call to retain_and_null_ptr(src_info), src_info is re-used for adding it to the global list. Getting the following kernel panic in papr_hvpipe_dev_create_handle() when trying to add src_info to the list. Kernel attempted to write user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on write at 0x00000000 Faulting instruction address:
    0xc0000000001b44a0 Oops: Kernel access of bad area, sig: 11 [#1] ... Call Trace:
    papr_hvpipe_dev_ioctl+0x1f4/0x48c (unreliable) sys_ioctl+0x528/0x1064 system_call_exception+0x128/0x360 system_call_vectored_common+0x15c/0x2ec Now, the error handling with FD_PREPARE's file cleanup and
    __free(kfree) auto cleanup is getting too convoluted. This is mainly because we need to ensure only 1 user get the srcID handle. To simplify this, we allocate prepare the src_info in the beginning and add it to the global list under a spinlock after checking that no duplicates exist. This simplify the error handling where if the FD_ADD fails, we can simply remove the src_info from the list and consume any pending msg in hvpipe to be cleared, after src_info became visible in the global list. (CVE-2026-46118)

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

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

  - spi：microchip-core-qspi：請勿嘗試在模擬唯讀雙/四操作期間傳輸 核心將透過建立時脈週期本身來處理讀取，無需透過在驅動程式層級傳輸垃圾資料來產生時脈週期。此外，傳輸垃圾數據只會使傳輸變得困難，因為 QSPI 沒有像常規 SPI 中的 MOSI 那樣的專用主輸出線。我不完全確定傳輸變磚是因為在匯流排上傳輸垃圾數據，還是因為內核失去了它應該發送還是接收數據的跟踪。（CVE-2026-46192）

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

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

  - 已解決 Linux 核心中的下列弱點：pseries/papr-hvpipe: Prevent kernel stack memory leak to userspace The hdr variable is allocated on the stack and only hdr.version and hdr.flags are initialized explicitly. Because the struct papr_hvpipe_hdr contains reserved padding bytes (reserved[3] and reserved2[40]), these could leak the uninitialized bytes to userspace after copy_to_user(). This patch fixes that by initializing the whole struct to 0. (CVE-2026-46182)

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

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

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

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

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

  - soc：mediatek：svs：修正 svs_enable_debug_write（） 中的記憶體洩漏 在 svs_enable_debug_write（） 中，如果 kstrtoint（） 失敗，則 memdup_user_nul（） 配置的 buf 會洩漏。透過使用 __free（kfree） 自動釋放 buf 來解決此問題，無需明確的 kfree（） 呼叫並防止洩漏。[安吉洛：
    新增缺少的 cleanup.h 包含] （CVE-2026-45881）

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

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

  - 已解決 Linux 核心中的下列弱點：eth: fbnic: Add validation for MTU changes Increasing the MTU beyond the HDS threshold causes the hardware to fragment packets across multiple buffers. If a single-buffer XDP program is attached, the driver will drop all multi-frag frames.
    While we can't prevent a remote sender from sending non-TCP packets larger than the MTU, this will prevent users from inadvertently breaking new TCP streams. Traditionally, drivers supported XDP with MTU less than 4Kb (packet per page). Fbnic currently prevents attaching XDP when MTU is too high. But it does not prevent increasing MTU after XDP is attached. (CVE-2026-45952)

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

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

  - 已解決 Linux 核心中的下列弱點：apparmor: fix NULL pointer dereference in __unix_needs_revalidation When receiving file descriptors via SCM_RIGHTS, both the socket pointer and the socket's sk pointer can be NULL during socket setup or teardown, causing NULL pointer dereferences in
    __unix_needs_revalidation(). This is a regression in AppArmor 5.0.0 (kernel 6.17+) where the new
    __unix_needs_revalidation() function was added without proper NULL checks. The crash manifests as: BUG:
    kernel NULL pointer dereference, address: 0x0000000000000018 RIP: aa_file_perm+0xb7/0x3b0 (or +0xbe/0x3b0, +0xc0/0x3e0) Call Trace: apparmor_file_receive+0x42/0x80 security_file_receive+0x2e/0x50 receive_fd+0x1d/0xf0 scm_detach_fds+0xad/0x1c0 The function dereferences sock->sk->sk_family without checking if either sock or sock->sk is NULL first. Add NULL checks for both sock and sock->sk before accessing sk_family. (CVE-2026-45966)

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

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

  - 已解決 Linux 核心中的下列弱點：rxrpc: Fix rxkad crypto unalignment handling Fix handling of a packet with a misaligned crypto length. Also handle non-ENOMEM errors from decryption by aborting. Further, remove the WARN_ON_ONCE() so that it can't be remotely triggered (a trace line can still be emitted). (CVE-2026-46085)

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

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

  - hwmon： （pt5161l） 修正 pt5161l_read_block_data（） 中的錯誤 修正 pt5161l_read_block_data（） 中的兩個錯誤： 1.
    緩衝區溢位：本機緩衝區 rbuf 宣告為 u8 rbuf[24]，但 i2c_smbus_read_block_data（） 最多可以傳回 I2C_SMBUS_BLOCK_MAX （32） 個位元組。i2c-core 會在檢查傳回值之前，將資料複製到呼叫端的緩衝區中，因此如果裝置傳回超過 24 個位元組，讀取後長度驗證不會防止堆疊溢位。將緩衝區大小調整為 I2C_SMBUS_BLOCK_MAX. 2。長度不相符的意外正返回：當所有三次重試都用盡時，因為裝置傳回具有意外長度的資料，i2c_smbus_read_block_data（） 會傳回正位元組計數。函式會直接傳回此值，而呼叫端會將任何非負傳回視為成功，處理過時或不完整的緩衝區內容。當重試用盡時傳回 -EIO，並以正傳回值，保留 I2C 失敗時的負錯誤碼。（CVE-2026-46001）

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

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

  - fbnic：關閉使用者與拆卸之間的fw_log爭用 修正拆卸路徑與fw_log寫入函式之間fw_log理論上的爭用。fw_log寫入 fbnic_fw_log_write（） 內，可從信箱處理常式 fbnic_fw_msix_intr（） 存取，但在清理期間，在 IRQ/MBX 拆卸之前釋放fw_log，導致解除參照釋放/空變數的潛在資料爭用。可能的交錯案例：
    CPU0： fbnic_fw_msix_intr（） // 條目 fbnic_fw_log_write（） if （fbnic_fw_log_ready（）） // true ...搶佔 ...
    CPU1： fbnic_remove（） // 項目 fbnic_fw_log_free（） vfree（log->data_start）;log->data_start = 空;CPU0：
    繼續、遍歷 log-> 項目或寫入 log->data_start初始化也有不正確的順序問題，因為 fw_log 目前是在初始化期間的 MBX 設定之後配置。藉由調整同步處理順序來修正問題，以便在啟用信箱之前進行初始化，直到停用信箱之後才清除。（CVE-2026-45977）

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

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

  - vfio/cdx：修正中斷觸發路徑中的 NULL 指標解除參照 新增驗證以確保在存取 vfio_cdx_set_msi_trigger（） 中的cdx_irqs陣列之前已設定 MSI。如果沒有此檢查，使用者空間可以在透過 VFIO_IRQ_SET_DATA_EVENTFD 設定中斷之前，呼叫具有 VFIO_IRQ_SET_DATA_BOOL 或 VFIO_IRQ_SET_DATA_NONE 旗標的VFIO_DEVICE_SET_IRQS，以觸發 NULL 指標解除參照。vfio_cdx_msi_enable（） 函式會配置 cdx_irqs 陣列，並僅在透過 EVENTFD 路徑呼叫時將 config_msi 設為 1。觸發迴圈 （針對 DATA_BOOL/DATA_NONE） 假設此動作已完成，但沒有強制執行此呼叫排序。這與 PCI VFIO 驅動程式中使用的保護相符，其中 vfio_pci_set_msi_trigger（） 會在觸發迴圈之前檢查 irq_is（）。（CVE-2026-46034）

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

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

  - 已解決 Linux 核心中的下列弱點：rust: pwm: Fix potential memory leak on init error When initializing a PWM chip using pwmchip_alloc(), the allocated device owns an initial reference that must be released on all error paths. If __pinned_init() were to fail, the allocated pwm_chip would currently leak because the error path returns without calling pwmchip_put().
    (CVE-2026-45926)

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

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

  - crypto：acomp - 修正 req->base.data 中 acomp_save_req（） acomp_save_req（） 儲存 &req->chain 所儲存的錯誤指標。在非同步完成時叫用 acomp_reqchain_done（） 時，它會接收 &req->chain 作為資料引數，但會直接將其轉換為結構acomp_req。由於資料指向鏈成員，因此所有後續欄位存取都處於錯誤的位移，導致記憶體損毀。當非同步硬體實作 （例如 QAT 驅動程式） 完成使用 DMA 虛擬位址介面 （例如 acomp_request_set_src_dma（）） 的要求時，就會發生此問題。這種組合會導致 crypto_acomp_compress（） 進入 acomp_do_req_chain（） 路徑，這會透過 acomp_save_req（） 將 acomp_reqchain_done（） 設定為完成回呼。啟用 KASAN 後，這表現為 acomp_reqchain_done（） 中的一般保護錯誤： 一般保護錯誤，可能針對非規範位址0xe000040000000000 KASAN：可能是 [0x0000400000000000-0x0000400000000007] 範圍內的使用者記憶體存取 RIP：
    0010：acomp_reqchain_done+0x15b/0x4e0 呼叫追蹤： <IRQ> qat_comp_alg_callback+0x5d/0xa0 [intel_qat] adf_ring_response_handler+0x376/0x8b0 [intel_qat] adf_response_handler+0x60/0x170 [intel_qat] tasklet_action_common+0x223/0x820 handle_softirqs+0x1ab/0x640 </IRQ> 透過將請求本身儲存在 req->base.data 而不是 &req->chain 中來解決此問題，以便 acomp_reqchain_done（） 接收正確的指標。相應地簡化 acomp_restore_req（） 以直接存取 req->chain。（CVE-2026-46081）

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

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

  - 在 、 之前 3.24.3Northern.tech CFEngine Enterprise 和 Community3.21.8，並3.27.0允許命令插入。（CVE-2026-24712）

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

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

  - Ubuntu Linux 6.8， 6.17 並 7.0 包含無法驗證 AppAmor 通知回應中名稱欄位大小無效的 SAUCE 修補程式。此錯誤可由無特權的本機使用者觸發，並可能導致處理特製的回應。（CVE-2026-47329）

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

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

  - GLPI 是免費的資產和 IT 管理軟體套件。在 的11.0.6版本11.0.0中，技術人員可以將 XSS 負載儲存在 ITIL 成本中。11.0.7 版已修正此問題。(CVE-2026-40108)

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

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

  - power： supply： pm8916_lbc： 修正 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-45938）

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

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

  - 已解決 Linux 核心中的下列弱點：media: iris: Fix use-after-free in iris_release_internal_buffers() The recent change in commit 1dabf00ee206 (media: iris: gen1: Destroy internal buffers after FW releases) introduced a regression where session_release_buf() may free the buffer. The caller, iris_release_internal_buffers(), continued to access `buffer` after the call, leading to a potential use-after-free. Fix this by setting BUF_ATTR_PENDING_RELEASE before calling session_release_buf(), and reverting the flag if the call fails. This ensures no dereference occurs after potential freeing. (CVE-2026-46240)

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

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

  - drm/msm/gem：修正 msm_ioctl_gem_info_get_metadata（） 中的錯誤處理 msm_ioctl_gem_info_get_metadata（） 無論錯誤為何，一律傳回 0。當 copy_to_user（） 失敗或使用者緩衝區太小時，儲存在 ret 中的錯誤碼會被忽略，因為函數無條件地傳回 0。這會導致使用者空間相信 ioctl 成功，但實際上沒有。此外，kmemdup（） 可以在配置失敗時傳回 NULL，但不會檢查傳回值。這會導致後續 copy_to_user（） 呼叫中出現 NULL 指標解除參照。對 kmemdup（） 新增缺少的 NULL 檢查，並傳回 ret 而不是 0。請注意，SET 對應部分 （msm_ioctl_gem_info_set_metadata） 正確傳回 ret。拼湊：
    https://patchwork.freedesktop.org/patch/714478/ (CVE-2026-46211)

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

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

  - mm/damon/core：驗證 damos_quota_goal->nid 的 node_mem_{used，free}_bp修補程式系列 mm/damon/core：
    驗證 damos_quota_goal->nid。node_mem[cg]_{used，free}_bp DAMOS 配額目標會收到節點 ID。節點 ID 用於 si_meminfo_node（） 和 NODE_DATA（），未經適當驗證。因此，特權使用者可以使用DAMON_SYSFS觸發越界記憶體存取。解決問題。此問題最初由另一位作者報告 [1]，並已修正。原作者宣布 [2] 他們將停止工作，包括仍處於審查階段的修復。因此我要重新開始這個。此修補程式（共 2 個）：使用者可以為 node_mem_{used，free}_bp 設定具有任意值的 damos_quota_goal->nid。但是 DAMON 核心在沒有驗證值的情況下將它們用於 si_meminfo_node（）。這可能會導致越界記憶體存取。該問題實際上可以使用 DAMON 使用者空間工具 （damo） 觸發，如下所示。$ sudo ./damo start --damos_action stat \ --damos_quota_goal node_mem_used_bp 50% -1 \
    --damos_quota_interval 1s $ sudo dmesg [...][ 65.565986] 無法在虛擬位址處理核心 NULL 指標解除參照 0000000000000098 透過新增給定節點的驗證來修正此問題。如果給出了無效的節點 ID，則會傳回 0% 的已用記憶體比率，並傳回 100% 的可用記憶體比率。
    (CVE-2026-46020)

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

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

  - 已解決 Linux 核心中的下列弱點：fs/ntfs3: fix ntfs_mount_options leak in ntfs_fill_super() In ntfs_fill_super(), the fc->fs_private pointer is set to NULL without first freeing the memory it points to. This causes the subsequent call to ntfs_fs_free() to skip freeing the ntfs_mount_options structure. This results in a kmemleak report: unreferenced object 0xff1100015378b800 (size 32): comm mount, pid 582, jiffies 4294890685 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ed ff ed ff 00 04 00 00 ................
    backtrace (crc ed541d8c): __kmalloc_cache_noprof+0x424/0x5a0 __ntfs_init_fs_context+0x47/0x590 alloc_fs_context+0x5d8/0x960 __x64_sys_fsopen+0xb1/0x190 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e This issue can be reproduced using the following commands:
    fallocate -l 100M test.file mount test.file /tmp/test Since sbi->options is duplicated from fc->fs_private and does not directly use the memory allocated for fs_private, it is unnecessary to set fc->fs_private to NULL. Additionally, this patch simplifies the code by utilizing the helper function put_mount_options() instead of open-coding the cleanup logic. (CVE-2025-71312)

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

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

  - 在 之前的 4.5.8warmcat libwebsockets 中發現一個缺陷。此問題會影響元件的 plugins/protocol_lws_ssh_base/sshd.c 檔案的功能lws_ssh_parse_plaintext SSH通訊協定處理常式。執行引數msg_len的操作可能會導致資源消耗。攻擊者可在遠端執行此攻擊。惡意利用已發布且可能遭到利用。此修補程式稱為 3f9f0c6ecaf0e6f3f219d30632c5d1f2479d7498。應套用修補程式來修復此問題。
    (CVE-2026-10650)

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

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

  - systeminformation 是用於 node.js 的系統和作業系統資訊庫。在 5.27.14 之前的版本中，Windows 系統上的 systeminformation 中的「fsSize()」函式容易受到作業系統命令插入的影響。可選的「drive」參數會在未經清理的情況下直接串連到 PowerShell 命令中，當使用者控制的輸入到達此函式時，允許執行任意命令。實際可利用性取決於應用程式如何使用此功能。如果應用程式未將使用者控制的輸入傳遞至「fsSize()」，則不會受到影響。5.27.14 版包含修補程式。(CVE-2025-68154)

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

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

  - 具有知識庫寫入權限的未經驗證的使用者可以將 XSS 承載儲存在知識庫項目中。此問題會影響 glpi： before 11.0.7。（CVE-2026-5385）

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

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

  - 已解決 Linux 核心中的下列弱點：accel/amdxdna: Fix race condition when checking rpm_on When autosuspend is triggered, driver rpm_on flag is set to indicate that a suspend/resume is already in progress. However, when a userspace application submits a command during this narrow window, amdxdna_pm_resume_get() may incorrectly skip the resume operation because the rpm_on flag is still set.
    This results in commands being submitted while the device has not actually resumed, causing unexpected behavior. The set_dpm() is called by suspend/resume, it relied on rpm_on flag to avoid calling into rpm suspend/resume recursivly. So to fix this, remove the use of the rpm_on flag entirely. Instead, introduce aie2_pm_set_dpm() which explicitly resumes the device before invoking set_dpm(). With this change, set_dpm() is called directly inside the suspend or resume execution path. Otherwise, aie2_pm_set_dpm() is called. (CVE-2025-71303)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/panthor: Fix NULL pointer dereference on panthor_fw_unplug This patch removes the MCU halt and wait for halt procedures during panthor_fw_unplug() as the MCU can be in a variety of states or the FW may not even be loaded/initialized at all, the latter of which can lead to a NULL pointer dereference. It should be safe on unplug to just disable the MCU without waiting for it to halt as it may not be able to. (CVE-2025-71307)

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

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

  - JavaScript Engine: JIT 元件中的 JIT 編譯錯誤。此弱點已在 Firefox 151.0.3中修正。（CVE-2026-10702）

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

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

  - 「圖形：文字」元件中的邊界條件不正確。此弱點已在 Firefox 151.0.3中修正。（CVE-2026-10701）

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

ID	名稱	嚴重性
318463	Linux Distros 未修補弱點：CVE-2026-46100	high
318462	Linux Distros 未修補弱點：CVE-2026-46048	medium
318461	Linux Distros 未修補弱點：CVE-2026-46213	high
318460	Linux Distros 未修補弱點：CVE-2026-44724	high
318459	Linux Distros 未修補弱點：CVE-2026-46087	medium
318458	Linux Distros 未修補弱點：CVE-2026-45967	medium
318457	Linux Distros 未修補弱點：CVE-2026-45865	medium
318456	Linux Distros 未修補弱點：CVE-2026-46104	medium
318455	Linux Distros 未修補弱點：CVE-2026-45947	medium
318454	Linux Distros 未修補弱點：CVE-2026-45990	medium
318453	Linux Distros 未修補弱點：CVE-2026-46215	high
318452	Linux Distros 未修補弱點：CVE-2026-46162	high
318451	Linux Distros 未修補弱點：CVE-2026-46138	high
318450	Linux Distros 未修補弱點：CVE-2026-45902	high
318449	Linux Distros 未修補弱點：CVE-2026-46097	high
318448	Linux Distros 未修補弱點：CVE-2026-46134	medium
318446	Linux Distros 未修補弱點：CVE-2026-46176	high
318445	Linux Distros 未修補弱點：CVE-2026-46154	high
318444	Linux Distros 未修補弱點：CVE-2026-46155	critical
318443	Linux Distros 未修補弱點：CVE-2026-46207	medium
318442	Linux Distros 未修補弱點：CVE-2026-47331	high
318441	Linux Distros 未修補弱點：CVE-2026-45969	medium
318440	Linux Distros 未修補弱點：CVE-2026-46118	medium
318439	Linux Distros 未修補弱點：CVE-2026-46192	medium
318438	Linux Distros 未修補弱點：CVE-2026-46182	medium
318437	Linux Distros 未修補弱點：CVE-2026-47327	low
318436	Linux Distros 未修補弱點：CVE-2026-45881	medium
318435	Linux Distros 未修補弱點：CVE-2026-45952	medium
318434	Linux Distros 未修補弱點：CVE-2026-45966	medium
318433	Linux Distros 未修補弱點：CVE-2026-46085	high
318432	Linux Distros 未修補弱點：CVE-2026-46001	high
318431	Linux Distros 未修補弱點：CVE-2026-45977	medium
318430	Linux Distros 未修補弱點：CVE-2026-46034	medium
318429	Linux Distros 未修補弱點：CVE-2026-45926	medium
318428	Linux Distros 未修補弱點：CVE-2026-46081	high
318427	Linux Distros 未修補弱點：CVE-2026-24712	high
318426	Linux Distros 未修補弱點：CVE-2026-47329	low
318425	Linux Distros 未修補弱點：CVE-2026-40108	high
318424	Linux Distros 未修補弱點：CVE-2026-45938	high
318423	Linux Distros 未修補弱點：CVE-2026-46240	high
318422	Linux Distros 未修補弱點：CVE-2026-46211	medium
318421	Linux Distros 未修補弱點：CVE-2026-46020	high
318420	Linux Distros 未修補弱點：CVE-2025-71312	medium
318419	Linux Distros 未修補弱點：CVE-2026-10650	high
318418	Linux Distros 未修補弱點：CVE-2025-68154	high
318417	Linux Distros 未修補弱點：CVE-2026-5385	high
318416	Linux Distros 未修補弱點：CVE-2025-71303	medium
318415	Linux Distros 未修補弱點：CVE-2025-71307	medium
318414	Linux Distros 未修補弱點：CVE-2026-10702	medium
318413	Linux Distros 未修補弱點：CVE-2026-10701	high

偵測

Nessus 的 Misc. 系列

high

medium

high

high

medium

medium

medium

medium

medium

medium

high

high

high

high

high

medium

high

high

critical

medium

high

medium

medium

medium

medium

low

medium

medium

medium

high

high

medium

medium

medium

high

high

low

high

high

high

medium

high

medium

high

high

high

medium

medium

medium

high