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

  - drm/rockchipdw_hdmi取消系結時清理 drm 編碼器這可修正 rmmod 期間的釋放後使用當機。
    DRM 編碼器內嵌在較大型的 rockchip_hdmi 內而該元件則隨該元件進行配置。元件記憶體在主要 drm 裝置遭到破壞前被釋放。透過在終止其容器之前執行編碼器清理來修正此問題。 [移動 clk_disable 之上的編碼器清理類似於 bind-error-path] (CVE-2023-54047)

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

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

  - btrfs啟動平衡時修正 exclop 條件的宣告因為獨占狀態與暫停的平衡和裝置新增相容這會使某些事情更複雜。從暫停的平衡開始宣告有效狀態時必須考慮另外兩個狀態當有數個執行緒爭用開始平衡與裝置新增時可能會命中組合。從命令行啟動命令時通常不會發生此情況。情境 1：使用 exclusive_operation state == BTRFS_EXCLOP_NONE。同時新增多個裝置至相同的掛載點且 btrfs_exclop_finish 已執行且未在 btrfs_exclop_balance 中的宣告之前完成獨占操作將變更為導致宣告失敗的 BTRFS_EXCLOP_NONE 狀態fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE || fs_info->exclusive_operation == BTRFS_EXCLOP_DEV_ADD在 fs/btrfs/ioctl.c:456 呼叫追踪 <TASK> btrfs_exclop_balance+0x13c/0x310 memdup_user+0xab/0xc0 ? PTR_ERR+0x17/0x20 btrfs_ioctl_add_dev+0x2ee/0x320 btrfs_ioctl+0x9d5/0x10d0 btrfs_ioctl_encoded_write+0xb80/0xb80
    __x64_sys_ioctl+0x197/0x210 do_syscall_64+0x3c/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd 情況 2
    使用 Exclusive_operation state == BTRFS_EXCLOP_BALANCE_PAUSED。同時新增多個裝置至相同的掛載點且 btrfs_exclop_balance 執行時在 btrfs_exclop_balance 中後一個執行緒執行宣告前結束、exclusive_operation 將變更為 BTRFS_EXCLOP_BALANCE_PAUSED 狀態進而導致宣告失敗fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE || fs_info->exclusive_operation == BTRFS_EXCLOP_DEV_ADD || fs_info->exclusive_operation == BTRFS_EXCLOP_NONEfs/btrfs/ioctl.c:458 呼叫追踪 <TASK> btrfs_exclop_balance+0x240/0x410 memdup_user+0xab/0xc0 ? PTR_ERR+0x17/0x20 btrfs_ioctl_add_dev+0x2ee/0x320 btrfs_ioctl+0x9d5/0x10d0 btrfs_ioctl_encoded_write+0xb80/0xb80
    __x64_sys_ioctl+0x197/0x210 do_syscall_64+0x3c/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd 失敗宣告範例如下所示其表示也需要檢查已暫停的餘額。
    root@syzkaller:/home/xsk# ./repro 無法新增裝置 /dev/vda、errno 14 無法新增裝置 /dev/vda、errno 14 無法新增裝置 /dev/vda、errno 14 無法新增裝置 / dev/vda、errno 14 無法新增裝置 /dev/vda、errno 14 無法新增裝置 /dev/vda、errno 14 無法新增裝置 /dev/vda、errno 14 無法新增裝置 /dev/vda、errno 14無法新增裝置 /dev/vda、errno 14 [ 416.611428][ T7970] BTRFS 資訊 (裝置 loop0): fs_info exclusive_operation: 0 無法新增裝置 /dev/vda、errno 14 [416.613973][ T7971] BTRFS info (裝置 loop0)fs_info exclusive_operation3 無法新增裝置 /dev/vdaerrno 14 [ 416.615456][ T7972] BTRFS 資訊 (裝置 loop0)fs_info exclusive_operation3 無法新增裝置 /dev/vdaerrno 14 [ 416.617528][ T7973] BTRFS 資訊 (裝置 loop0)fs_info exclusive_operation3 新增裝置 /dev/vda 失敗errno 14 [ 416.618359][ T7974] BTRFS 資訊 (裝置 loop0)fs_info exclusive_operation 3無法新增裝置 /dev/vdaerrno 14 [ 416.622589][ T7975] BTRFS 資訊 (裝置 loop0)fs_info exc lusive_operation: 3 無法新增裝置 /dev/vda、errno 14 [ 416.624034][T7976] BTRFS 資訊 (裝置 loop0)fs_info exclusive_operation3 無法新增裝置 /dev/vda、errno 14 [416.626420][ T7977] BTRFS 資訊 (裝置 loop0)fs_info exclusive_operation3 無法新增裝置 /dev/vdaerrno 14 [ 416.627643][ T7978] BTRFS 資訊 (裝置 loop0)fs_info exclusive_operation3 無法新增裝置 /dev/ vda、errno 14 [ 416.629006][ T7979] BTRFS 資訊 (裝置 loop0): fs_info exclusive_operation: 3 [ 416.630298][ T7980] BTRFS 資訊 (裝置 loop0): fs_info exclusive_operation: 3 Fai
    ---truncated--- (CVE-2023-54002)

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

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

  - ntfs3修正 __getname() 配置的 uninit 緩衝區。修正將緩衝區配置提供給 'de' 後所造成的 uninit 錯誤以零初始化緩衝區。此修正是使用 KMSAN 發現的。 (CVE-2025-68727)

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

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

  - netdevsim修正 nsim_bus_dev_new() 中的記憶體洩漏問題如果 nsim_bus_dev_new() 中的 device_register() 失敗則 nsim_bus_dev->dev 中的參照值為 1。nsim_bus_dev->dev 中的 obj->name 將不會釋放。
    未參照的物件 0xffff88810352c480 (大小 16)comm echo、pid 5691、jiffies 4294945921 (133.270s) 十六進位轉儲存 (前 16 個位元組)6e 65 74 64 65 76 73 69 6d 31 00 00 00 00 00 00 netdevsim1.... .. backtrace
    [<000000005e2e5e26>] __kmalloc_node_track_caller+0x3a/0xb0 [<0000000094ca4fc8>] kvasprintf+0xc3/0x160 [<00000000aad09bcc>] kvasprintf_const+0x55/0x180 [<000000009bac868d>] kobject_set_name_vargs+0x56/0x150 [<000000007c1a5d70>] dev_set_name+0xbb/0xf0 [<00000000ad0d126b>] device_add +0x1f8/0x1cb0 [<00000000c222ae24>] new_device_store+0x3b6/0x5e0 [<0000000043593421>] bus_attr_store+0x72/0xa0 [<00000000cbb1833a>] sysfs_kf_write+0x106/0x160 [<00000000d0dedb8a>] kernfs_fop_write_iter+0x3a8/0x5a0 [<00000000770b66e2>] vfs_write [/x8f0] [+0x8f0<0000000078bb39be>] ksys_write+0x106/0x210 [<00000000005e55a4>] do_syscall_64+0x35/0x80 [<00000000eaa40bbc>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-50772)

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

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

  - cryptoaead - 修正 reqsize 處理提交 afddce13ce81d (cryptoapi - 新增 reqsize 至 crypto_alg) 在 crypto_alg 結構中引入了 cra_reqsize 欄位以取代特定類型的 reqsize 欄位。這似乎是專門針對認可描述中的 ahash 和 acomp 而引入的因為後續認可會在這些 alg 架構中新增必要的變更。不過建議所有密碼編譯 algs 使用此方法來取代使用 crypto_*_set_reqsize() 來設定 reqsize。因此在 aead 演算法中使用 cra_reqsize 會造成記憶體損毀及當機因為演算法架構中的基礎函式尚未更新為從 cra_reqsize 正確設定 reqsize。 [1] 在 aead init 函式中新增適當的 set_reqsize 呼叫以便在架構中正確初始化這些演算法的 reqsize。 [1]
    https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b (CVE-2025-68726)

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

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

  - block修正 __blkdev_issue_zero_pages 中的記憶體洩漏在已設定 BLKDEV_ZERO_KILLABLE 且嚴重訊號擱置時將嚴重訊號檢查移至 bio_alloc() 之前移動以防止記憶體洩漏。之前在檢查嚴重訊號之前配置 bio。如果訊號擱置則程式碼會中斷迴圈而不釋放或鏈結剛剛配置的 bio進而造成記憶體洩漏。這符合 __blkdev_issue_write_zeroes() 中已使用的模式其中訊號檢查在配置之前。
    (CVE-2025-68348)

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

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

  - configfs修正 configfs_create_dir() 中可能發生的記憶體洩漏 kmemleak 報告在 configfs_create_dir() 中發生記憶體洩漏未參照物件 0xffff888009f6af00 (大小 192)comm modprobe、pid 3777、jiffies 4295537735 (233.784s) 反向追踪kmem_cache_alloc (mm/slub. :3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs /configfs/dir.c:1857) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... 未參照物件 0xffff888003ba7180 (大小 96)comm modprobe、pid 3777、jiffies 4295537735 (233.784s) 反向追踪 kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c :3273) configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/config fs/dir.c:852) configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module /main.c:2455) ... 這是因為 configfs_make_dirent() 中的 refcount 不正確。在一般階段refcount 變更如下 configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2 ... configfs_unregister_subsystem() configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ... *dentry_unlink_inode()* configfs_d_iput() # s_count = 0, release 但是如果我們在 configfs_create (): configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count = 2 ... configfs_create() # fail ->out_remove
    configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1 return PTR_ERR(inode);錯誤路徑中沒有 inode因此 configfs_d_iput() 會遺失導致 sd 和片段記憶體洩漏。為修正此問題我們在 configfs_create() 中失敗時需手動呼叫 configfs_put(sd) 以保持 refcount 正確無誤。
    (CVE-2022-50751)

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

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

  - 藍牙修正 hidp_session_thread 中的爭用情形 hidp_session_thread 中有可能導致釋放後使用的爭用情形。例如當在 hidp_session_thread() 中呼叫 hidp_del_timer 時計時器會作用。在 hidp_session_put 之後「工作階段」將會被釋放進而在 hidp_idle_timeout 執行時造成核心錯誤。解決方案是使用 del_timer_sync 而非 del_timer。呼叫追踪如下hidp_session_probe+0x780/0x780 call_timer_fn+0x2d/0x1e0
    __run_timers.part.0+0x569/0x940 hidp_session_probe+0x780/0x780 call_timer_fn+0x1e0/0x1e0 ktime_get+0x5c/0xf0 lapic_next_deadline+0x2c/0x40 clockevents_program_event+0x205/0x320 run_timer_softirq+0xa9/0x1b0 __do_softirq+0x1b9/0x641 __irq_exit_rcu+0xdc/0x190 irq_exit_rcu +0xe/0x20 sysvec_apic_timer_interrupt+0xa1/0xc0 (CVE-2023-54120)

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

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

  - 序列sprd修正 DMA 緩衝區洩漏問題當 _probe() 傳回失敗時釋放 DMA 緩衝區以避免記憶體洩漏。 (CVE-2023-54136)

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

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

  -ulator: core在未鎖定 Regulator_supply_alias()、regulator_register_supply_alias() 和 Regulator_unregister_supply_alias() 中存取負責人 Regulator_supply_alias_list 的ulator_supply_alias_list。並行註冊、取消註冊和查閱可能會發生爭用進而導致︰1 會在讀取別名項目時發生釋放後使用、2 個執行緒註冊相同別名時會發生重複項目、3 會使用者觀察到不一致的別名對應。以現有的 Regulator_list_mutex 保護 Regulator_supply_alias_list 上的所有遊走、插入和刪除。
    (CVE-2025-68354)

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

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

  - USB小工具修正 usb config 切換期間的釋放後使用。可能造成 ->pullup 回呼失敗進而造成系統錯誤 (釋放後使用)。無論硬體的行為為何小工具驅動程式有時都需要卸載。分析如下============================================== ========================= (1) write /config/usb_gadget/g1/UDC none gether_disconnect+0x2c/0x1f8 rndis_disable+0x4c/0x74 Composite_disconnect+ 0x74/0xb0 configfs_composite_disconnect+0x60/0x7c usb_gadget_disconnect+0x70/0x124 usb_gadget_unregister_driver+0xc8/0x1d8 gadget_dev_desc_UDC_store+0xec/0x1e4 (2) rm /config/usb_gadget/g1/configs/b.1/f1 rndis_deregister_driver+0x+2840/x54 0x7c usb_put_function+0x14/0x1c config_usb_cfg_unlink+0xc4/0xe0 configfs_unlink+0x124/0x1c8 vfs_unlink+0x114/0x1dc (3) rmdir /config/usb_gadget/g1/functions/rndis.gs4 panic+0x1fc/0x3d0 do_page_fault+meditor8/000x3c /0xac el1_sync_handler+0x40/0x78 0xffffff801138f880 rndis_close+0x28/0x34 eth_stop+0x74/0x110 dev_close_many+0x48/0x194 rollback_registered_many+0x118/0x814 unregister_netdev+0x20/0x30 gether_cleanup+0x1c/0x38 rndis_attr_release+0xc/0x14 kref_put+0x74/0xb8 configfs_rmdir+ 0x314/0x374 如果 gadget->ops->pullup() 傳回錯誤則會呼叫 rndis_close() 函式然後造成釋放後使用問題。
    ================================================== ===================== (CVE-2022-50704)

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

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

  - cryptoasymmetric_keys - 防止 asymmetric_key_generate_id 中發生溢位 新增 asymmetric_key_id 結構的二進位 blob 長度和大小時使用 check_add_overflow() 防止可能的整數溢位並傳回 ERR_PTR(-EOVERFLOW)。這可在從可能為任意大的潛在惡意 X.509 憑證欄位 (例如 ASN.1 INTEGER 序號、簽發者名稱等) 複製資料時防止可能的緩衝區溢位 (CVE-2025-68724)

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

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

  - bpf新增 preempt_count_{sub,add} 到 btf id 拒絕清單 __bpf_prog_enter* 和 中的遞回檢查
    __bpf_prog_exit* 讓 preempt_count_{sub,add} 不受到保護。當在其中附加 trampoline 時我們會發生如下錯誤 [ 867.843050] 錯誤TASK 堆疊保護頁面在 0000000009d325cf 遭到命中 (堆疊為 0000000046a46a15..00000000537e7b28) [ 867.843064] 堆疊保護頁面 0000 [#1] PREEMPT SMP NOPTI [867.843067] CPU8 PID11009 通訊追踪 Kdump 已載入 未受污染 6.2.0+ #4 [ 867.843100] 呼叫追踪 [867.843101] [] <TASK> [ 867.843104] asm_exc_int3+0x3a/0x40 [ 867.843108] RIP 0010:preempt_count_sub+0x1/0xa0 [ 867.843135] __bpf_prog_enter_recur+0x17/0x90 [ 867.843148] bpf_trampoline_6442468108_0+0x2e/0x1000 [867.843154] ? preempt_count_sub+0x1/0xa0 [ 867.843157] preempt_count_sub+0x5/0xa0 [ 867.843159] ? migrate_enable+0xac/0xf0 [ 867.843164] __bpf_prog_exit_recur+0x2d/0x40 [ 867.843168] bpf_trampoline_6442468108_0+0x55/0x1000 ... [ 867.843788] preempt_count_sub+0x5/0xa0 [ 867.843793] migrate_enable+0xac/0xf0 [ 867.843829] __bpf_prog_exit_recur+0x2d/0x40 [ 867.843837] 錯誤 IRQ 堆疊保護頁面於 0000000099bd8228 遭到攻擊 (堆疊為 00000000b23e2bc4..000000006d95af35) [ 867.843841] 錯誤 IRQ 堆疊保護頁面於 9000 年 2 月 20 日遭點擊(堆疊為 00000000ffd69623..0000000014eb594c) [ 867.843843] 錯誤IRQ 堆疊保護頁面在 00000000028320f0 遭到命中 (堆疊為 00000000034b6438..0000000078d1bcec) [867.843842] bpf_trampoline_...0x420/60x100_0+64520/608100_0 這是因為在 __bpf_prog_exit_recur 中會在 prog->active 減少後呼叫 preempt_count_{sub,add}。透過將這兩個函式新增至 btf ids 拒絕清單來修正此問題。 (CVE-2023-54086)

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

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

  - netfilternf_tables修正鏈結參照中的反向溢位設定元素附加錯誤路徑會遞減鏈結上的參照計數器第一次是在元素釋放時再次透過 nft_data_release()。然後d6b478666ffa (netfilternf_tables修正物件參照計數器中的反向溢位) 藉由移除有狀態物件參照計數遞減錯誤地修正了此問題。還原 b91d90368837 中一樣的有狀態物件遞減 (netfilternf_tables修正洩漏的物件參照計數)並讓 nft_data_release() 遞減鏈結參照計數器因此此動作只會執行一次。 (CVE-2023-54035)

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

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

  - binder修正 alloc->vma 在與 munmap() 爭用中的 UAF [ cmllamas從提交 015ac18be7de 清除轉送連接埠 (binder修正 alloc->vma 在與 munmap() 爭用中的 UAF) 5.10 穩定版。如 Liam 所指出的還原認可 a43cfc87caaf 後在主線中需要它 (androidbinder停止儲存 VMA 的指標)。已調整認可記錄和標籤以反映此問題。 ] 在認可 720c24192404 中 (ANDROIDbinder將 down_write 變更為 down_read)binder 假設 mmap 讀取鎖定足以保護 binder_update_page_range() 內的 alloc->vma。這在提交 dd2283f2605e 之前一直是正確的 (mmmap在 munmap 中具有讀取 mmap_sem 的 zap 頁面)現在在 munmap() 中將 vma 從 rbtree 卸離之後會降級 mmap_lock。然後在保留讀取鎖定的情況下繼續卸除並釋放 vma。這表示binder_update_page_range() 中的 alloc->vma 存取現在會與 munmap() 中的 vm_area_free() 爭用且可造成如下列 KASAN 追踪所示的 UAF
    ================================================== ================ 錯誤KASAN在 vm_insert_page+0x7c/0x1f0 中發生釋放後使用錯誤由 task server/558 CPU於 addr ffff16204ad00600 讀取大小為 8 的 CPU: 3 PID: 558 Comm在
    伺服器 未受污染 5.10.150-00001-gdc8dcf942daa #1 硬體名稱 linux,dummy-virt (DT) 呼叫追踪
    dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction +0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c
    __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 由 5x093:/0kasanx6_c_stack 工作配置
    __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common .constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 已由工作 560 釋放
    kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c
    __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc +0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 [...] ========================== ======================================== 若要防止上述爭用情形請回復為採取binder_update_page_range() 中的 mmap 寫入鎖定。預期 mmap 鎖定爭用可能有所增加。不過binder 已透過頂層 alloc->mutex 序列化這些呼叫。此外執行資料夾基準測試時不會顯示任何效能影響。
    (CVE-2023-54157)

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

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

  - mptcp修正 fastopen 提早遞補上的 NULL 指標解除參照。若提早遞補至 TCPsubflow_syn_recv_sock() 會在將新配置的 sock 傳回給呼叫者之前刪除子流程內容。fastopen 路徑無法處理上述無條件解除參照子流程內容的問題。
    (CVE-2023-54085)

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

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

  - drm/fbdev-generic禁止潛在的超出邊界存取。IGT 的 fbdev 測試可在 EOF 之後寫入進而導致具有 fbdev-generic 的 drm 驅動程式超出邊界存取。例如若在 x86+ast2400 平台上以 1680x1050 的解析度執行 fbdev 測試將會造成 linux 核心懸置並造成下列呼叫追踪Oops0000 [#1] PREEMPT SMP PTI [IGT] fbdev啟動子測試 eof Workqueue事件drm_fb_helper_damage_work [drm_kms_helper] [IGT] fbdev開始 subtest nullptr RIP
    0010:memcpy_erms+0xa/0x20 RSP: 0018:ffffa17d40167d98 EFLAGS: 00010246 RAX: ffffa17d4eb7fa80 RBX
    ffffa17d40e0aa80 RCX: 00000000000014c0 RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000 RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0 R10: ffffa17d4e4c5000 R11:
     R120000000000000000  : ffffa17d4eb7fa80 R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30 FS: 0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR400000000001706e0 呼叫追踪 <TASK> drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper] drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper] process_one_work+0x21f/0x430 worker_thread+0x4e/0x3c0 __pfx_worker_thread+0x10/0x10 kthread+0xf4/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> CR2: ffffa17d40e0b000 ---[end trace 0000000000000000 ]--- 這是因為 drm_fb_helper_memory_range_to_clip() 函式計算的損壞矩形不保證一定會在畫面的使用中顯示區域內。可能的原因有1) 針對 mmap 系統呼叫支援以頁面大小的細微度配置緩衝區。fbdev 模擬消耗的陰影畫面緩衝區也可選擇為頁面大小對齊。 2) drm_fb_helper_memory_range_to_clip() 中使用的 DIV_ROUND_UP() 會引入差一錯誤。例如在 16KB 頁面大小的系統上為了儲存 1920x1080 XRGB 框架緩衝區我們需要配置 507 頁面。遺憾的是大小 1920*1080*4 無法完全除以 16KB。 1920 * 1080 * 4 = 8294400 位元組 506 * 16 * 1024 = 8290304 位元組 507 * 16 * 1024 = 8306688 位元組 line_length = 1920*4 = 7680 位元組 507 * 16 * 1024 / 7680 = 1081.6 off / line_length = 507 * 16 1024 / 7680 = 1081 DIV_ROUND_UP(507 * 16 * 1024, 7680) 會發生 1082 memcpy_toio() 通常逐行發出複制但在復制最後一行時會發生超出邊界存取。因為1082 * line_length = 1082 * 7680 = 8309760且 8309760 > 8306688 請注意如果暴露的緩衝區大於寬度 x 跨度則使用者空間可能仍會寫入隱藏區域。但若目前未繪圖則只要仍有記憶體可解決存取權問題就不是大問題。- 也限制 y1 (Daniel) - 將其修正修補程式保持在最低限度 (Daniel) - screen_size 是頁面大小對齊因為它需要 mmap (Thomas) - 新增修正標籤 (Thomas) (CVE-2023-54116)

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

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

  - mediaimx-jpeg停用無用的插斷以避免核心錯誤。存在一個硬體錯誤可能會在停用插斷之後或時觸發插斷 STMBUF_HALF。這可能會導致未預期的核心錯誤。且中斷 STMBUF_HALF 與 STMBUF_RTND 不會有其他影響。因此請將其及未使用的插斷停用。同時在停用中斷時清除中斷狀態。 (CVE-2022-50741)

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

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

  - scsilpfc修正從 debugfs 讀取 rx_monitor 時的硬鎖定。在 /sys/kernel/debug/lpfc/fnX/rx_monitor 的 I/O 和同時 cat 期間可能會發生與下列呼叫追踪類似的硬鎖定。lpfc_rx_monitor_report 中的 spin_lock_bh 並未如預期地防止計時器中斷請將微調鎖定的強度變更為 _irq。Kernel panic - not syncing: Hard LOCKUP CPU: 3 PID: 110402 Comm: cat Kdump: loaded exception RIP: native_queued_spin_lock_slowpath+91 [IRQ stack] native_queued_spin_lock_slowpath at ffffffffb814e30b _raw_spin_lock at ffffffffb89a667a lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc] lpfc_cmf_timer at ffffffffc0abbc67 [lpfc]
    __hrtimer_run_queues at ffffffffb8184250 hrtimer_interrupt at ffffffffb8184ab0 smp_apic_timer_interrupt at ffffffffb8a026ba apic_timer_interrupt at ffffffffb8a01c4f [End of IRQ stack] apic_timer_interrupt at ffffffffb8a01c4f lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc] lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc] full_proxy_read at ffffffffb83e7fc3 vfs_read at ffffffffb833fe71 ksys_read at ffffffffb83402af do_syscall_64 at ffffffffb800430b entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad (CVE-2022-50744)

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

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

  - NFSv4/pNFS清除 pnfs_mark_layout_stateid_invalid 中的 NFS_INO_LAYOUTCOMMIT。修正在此呼叫堆疊期間因版面為 null 而發生的當機問題write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit 仰賴 lseg refcount 保留版面配置。需要清除 NFS_INO_LAYOUTCOMMIT否則我們可能會嘗試參照 null 配置。 (CVE-2025-68349)

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

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

  - autofs修正 autofs_catatonic_mode 中的 waitqueues 記憶體洩漏。Syzkaller 報告記憶體洩漏錯誤
    記憶體洩漏未參照物件 0xffff88810b279e00 (大小 96)comm syz-executor399、pid 3631、jiffies 4294964921 (23.870s) 十六進位轉儲存 (前 32 個位元組)00 00 00 00 00 00 00 00 08 9e 27 0b 81 8 8 ff. ff .....'....... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'........ 反向追踪
    [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [內嵌] [<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c 378 [<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593 [<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619 [<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/ root.c:897 [<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [內嵌] [<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [內嵌] [<ffffffff81602a9c>] __se_sys_ioctl fs/ioctl.c:856 [內嵌] [<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [內嵌] [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] 如果 wait_ctr 變為零則應釋放 entry_SYSCALL_64_after_hwframe+0x63/0xcd autofs_wait_queue 結構。否則將會遺失。在此情況下AUTOFS_IOC_EXPIRE_MULTI ioctl 會完成然後在 autofs_wait() 中配置新的 waitqueue 結構且其初始 wait_ctr 等於 2。在此之後 wait_event_killable() 會中斷 (它傳回 -ERESTARTSYS)因此「wq->name.name == NULL」的條件可能未得到滿足。實際上此條件可在呼叫 autofs_wait_release() 或 autofs_catatonic_mode() 時滿足而且同樣重要的是這些位置中的 wait_ctr 會遞減。
    autofs_wait() 結束時wait_ctr 遞減至 1。然後卸載處理程序開始kill_sb 呼叫 autofs_catatonic_mode()其應已釋放 waitqueues但只會將其使用量計數器遞減為零此行為不正確。 edit:imk 此描述當然不正確。因到期而執行的卸載是對已自動掛載的掛載進行的卸載而非 autofs 掛載本身。這些問題會獨立發生，通常是在 autofs 檔案系統中掛載的所有項目都已過期移走之後。如果所有項目都尚未到期自動掛載程序仍可結束將掛載保留在適當位置。但是在這兩種情況下完成的到期作業都會導致發出通知以結果狀態呼叫 autofs_wait_release()。問題案例為自動掛載程序的摘要執行。在此情況下任何等候的處理程序都不會被喚醒直到它們終止或卸載完成為止。 end edit: imk因此在 catatonic 模式中我們應該釋放計數器變為零的 waitqueue。
    編輯imk 最初我還擔心 autofs_wait_release() 和 autofs_catatonic_mode() 的呼叫不是互斥的但事實並非如此 (顯然)因為當其中任何一個發生時佇列項目都會從清單中移除。會呼叫兩個函式。因此這些函式中的其中一個或 autofs_wait() 中喚醒的處理程序將視呼叫順序而定這些函式將釋放等待項目。結束編輯imk (CVE-2023-54134)

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

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

  - NSF Unidata NetCDF-C 變數名稱堆疊型緩衝區溢位遠端程式碼執行弱點。此弱點允許遠端攻擊者在 NSF Unidata NetCDF-C 的受影響安裝上執行任意程式碼。刺探利用此弱點需要使用者互動，因為目標必須造訪惡意頁面或開啟惡意檔案。特定瑕疵存在於變數名稱的剖析中。
    此問題是因為未正確驗證使用者提供的資料長度，便將其複製到固定長度的堆疊型緩衝區所致。攻擊者可利用此弱點，在目前使用者的內容中執行程式碼。為 ZDI-CAN-27267。 (CVE-2025-14934)

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

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

  - ALSAwavefront修正範例大小驗證中的整數溢位。wavefront_send_sample() 函式在驗證範例大小時有一個整數溢位問題。header->size 欄位是 u32但為了與 dev->freemem 比較會轉換為 int 透過使用無正負號的比較來修正以避免整數溢位。
    (CVE-2025-68344)

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

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

  - ceph修正修剪端點時可能發生的釋放後使用錯誤回呼將會觸發釋放後使用當機。我們需要在取得 'ci->i_ceph_lock' 之後檢查該端點是否存在。若已移除則不執行任何動作。 (CVE-2023-53867)

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

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

  - ext4如果 Yi 在檢閱修補程式時發現啟用配額後掛載失敗則關閉配額 ext4
    當 ext4_mark_recovery_complete() 傳回錯誤值時錯誤處理路徑未關閉已啟用的配額不會在不一致的日誌功能上執行 BUG進而觸發下列 kmemleak
    ================================================== ============== 未參照的物件 0xffff8cf68678e7c0 (大小 64)comm mount, pid 746, jiffies 4294871231 (age 11.540s) hex dump (前 32 個位元組)00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00 ....A....c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00 ....... ...H... 反向追踪 [<00000000c561ef24>] __kmem_cache_alloc_node+0x4d4/0x880 [<00000000d4e621d7>] kmalloc_trace+0x39/0x140 [<00000000837eee74>] v2_read_file_info+0x18a/0x3a0 [<0000000088f6c877>] dquot_load_quota_sb+0x2ed/0x770 [<00000000340a4782>] dquot_load_quota_inode +0xc6/0x1c0 [<0000000089a18bd5>] ext4_enable_quotas+0x17e/0x3a0 [ext4] [<000000003a0268fa>]
    __ext4_fill_super+0x3448/0x3910 [ext4] [<00000000b0f2a8a8>] ext4_fill_super+0x13d/0x340 [ext4] [<000000004a9489c4>] get_tree_bdev+0x1dc/0x370 [<000000006e723bf1>] ext4_get_tree+0x1d/0x30 [ext4] [<00000000c7cb663d>] vfs_get_tree+0x31/0x160 [<00000000320e1bed>] do_new_mount+0x1d5/0x480 [<00000000c074654c>] path_mount+0x22e/0xbe0 [<0000000003e97a8e>] do_mount+0x95/0xc0 [<000000002f3d3736>]
    __x64_sys_mount+0xc4/0x160 [<0000000027d2140c>] do_syscall_64+0x3f/0x90 ==================================== ============================ 為解決此問題我們新增了 failed_mount10 標籤並在此標籤中呼叫 ext4_quota_off_umount() 以釋放已啟用 qoutas。
    (CVE-2023-54153)

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

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

  - md在 md_run() 之前可能需要 mddev_init IO 作業中的 init bioset例如在寫入 sysfs 後更新詮釋資料。在沒有 bioset 的情況下這會觸發 NULL 指標解除參照如下錯誤核心 NULL 指標解除參照位址0000000000000020 呼叫追踪 md_update_sb+0x658/0xe00 new_level_store+0xc5/0x120 md_attr_store+0xc9/0x1e0 sysfs_kf_write+0x6f/0xa0 kernx14_f/x 寫入_0+02_0+0 vfs_write+0x1fc/0x5a0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x2818/0x2880 do_syscall_64+0xa9/0x580 entry_64_after_hwframe+0x4b/0x53 複製器 d`SYSCALL_64_after_hwframe+0x4b/0x53 複製器 d`SYSCALL_64_after_hwframe+0x4b/0x53 複製程式 d`SYSCALL_``mdadm2 -CR//dev/md0`` mdadm2 -CR cd] echo inactive > /sys/block/md0/md/array_state echo 10 > /sys/block/md0/md/new_level ``` mddev_init() 每個 mddev 只能呼叫一次無需測試 bioset 是否已已初始化。 (CVE-2025-68368)

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

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

  - btrfs修正 btrfs_clear_space_info_full() 中爭用的 bitfield 寫入。來自關於記憶體障礙排序保證的 memory-barriers.txt 文件(*) 這些保證不適用於 bitfields因為編譯器通常會使用非原子讀取產生修改這些位元欄位的程式碼modify-write 序列。不嘗試使用位元欄位同步平行演算法。 (*) 即使位元欄位受到鎖定保護特定位元欄位中的所有欄位也必須受到一個鎖定的保護。如果指定位元欄位中的兩個欄位受到不同的鎖定保護編譯器的非原子讀取-修改-寫入序列可造成其中一個欄位的更新損毀相鄰欄位的值。 btrfs_space_info 有一個位元欄位共用由欄位 full、chunk_alloc 和 flush 所組成的基礎文字struct btrfs_space_info { struct btrfs_fs_info
    * fs_info /* 0 8 */ struct btrfs_space_info * parent /* 8 8 */ ... int squeeze; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1 /* 1761 4 */ unsigned int flush:1; /* 1762 4 */ ...
    因此為了避免平行的 read-modify-writes 遺失對受鎖定保護之其中一個位元欄位成員的寫入所有對所有位元欄位的寫入都必須使用該鎖定。它們幾乎普遍存在除了 btrfs_clear_space_info_full() 會反覆使用 space_infos 並在沒有鎖定的情況下寫出 found->full = 0。假設我們有一個執行緒完成一筆交易我們在此交易中完成了 block_group 的刪除因此正在呼叫 btrfs_clear_space_info_full()而同時資料回收票證基礎結構正在執行 do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full 0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0 READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock);傳回MOD/WRITEfull:0、chunk_alloc:0、flush:1 現在 data_sinfo->flush 為 1但回收背景工作已經結束。如果沒有工作在佇列或執行這會破壞排清為 0 的不變式。一旦違反此不變量，則進入
    __reserve_bytes() 會將票證新增至 space_info->tickets但會看到 space_info->flush 設為 1且不會將工作排入佇列。在此之後它們會在產生的票證上永遠封鎖因為現在不可能再次啟動該背景工作。我也查看了受影響核心的組件以確認其正在執行 RMW 作業。例如要將排清 (3rd) 位元設為 0該組件為andb $0xfb,0x60(%rbx)而將完整 (1st) 位元設為 0 的程式集為 andb $0xfe,-0x20(%rax)所以我認為這確實是實際系統上的錯誤。我發現有數個系統處於此確切狀態但目前無法重現。與其讓這個 Footgun 等到日後閒置不如利用結構中無論如何都有空間而且結構已經相當大簡單地將三個 bitfield 成員變更為 bools 的事實。這可避免寫入 space_info->full 對 造成任何影響 ---truncated--- (CVE-2025-68358)

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

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

  - acct修正 encode_comp_t() 中潛在的整數溢位。整數溢位由下列程式碼描述> 317 static comp_t encode_comp_t(u64 value) > 318 { > 319 int exp, rnd; ...... > 341 exp <<= MANTSIZE; > 342 exp += value > 343 傳回 exp > 344 } 目前 comp_t 定義為「__u16」類型但變數「exp」是「int」類型因此當第 343 行中的變數「exp」大於 65535 時會發生溢位。(CVE-2022-50749)

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

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

  - phytegraxusb清除 usb-phy dev 中的驅動程式參照。針對雙重角色連接埠它會將 phy dev 指派給 usb-phy dev並將連接埠 dev 驅動程式做為 usb-phy 的 dev 驅動程式使用。當我們嘗試損毀連接埠 dev 時其也會損毀其 dev 驅動程式。但我們並未從 usb-phy dev 中移除參照。
    這可能會造成 KASAN 發生釋放後使用問題。 (CVE-2023-54083)

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

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

  - x86/apic鎖定時不停用 x2APIC。APIC 支援兩種模式舊版 APIC (或 xAPIC) 和延伸 APIC (或 x2APIC)。X2APIC 模式大多與舊版 APIC 相容但它會停用記憶體對應的 APIC 介面而偏好使用 MSR 的介面。APIC 模式由 APIC MSR 中的 EXT 位元控制。
    MMIO/xAPIC 介面有一些問題最明顯的是 APIC 洩漏 [1]。此錯誤允許攻擊者使用 APIC MMIO 介面從 SGX enclave 擷取資料。引入新功能的支援將允許 BIOS 在 x2APIC 模式下鎖定 APIC。如果 APIC 在 x2APIC 模式下鎖定而核心嘗試停用 APIC 或還原至舊版 APIC 模式則會發生 GP 錯誤。引入新 MSR (IA32_XAPIC_DISABLE_STATUS) 的支援並在設定 LEGACY_XAPIC_DISABLED 位元時透過防止核心嘗試停用 x2APIC 來處理新的鎖定模式。在具有 IA32_XAPIC_DISABLE_STATUS MSR 的平台上如果啟用 SGX 或 TDXLEGACY_XAPIC_DISABLED 將會由 BIOS 設定。如果需要舊版 APIC則必須在 BIOS 中停用 SGX 和 TDX。 [1]
    https://aepicleak.com/aepicleak.pdf (CVE-2022-50720)

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

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

  - drm/panthor防止在群組建立中潛在的 UAF 此提交可防止 GROUP_CREATE ioctl 函式中發生釋放後使用問題的可能性該問題是因為在將 ioctl 函式儲存在 Xarray 之後在該 ioctl 函式中存取群組指標時所產生的。惡意使用者空間可再次猜測群組的處置程式並嘗試在與 GROUP_CREATE ioctl 相同的時間從另一個執行緒呼叫 GROUP_DESTROY ioctl。
    為防止釋放後使用惡意利用此提交在群組集區 Xarray 的項目上使用了剛好在從 GROUP_CREATE ioctl 函式傳回之前新增的標記。系統會針對所有指定群組控制代碼的 ioctl 檢查標記因此使用者空間不會 abe 刪除尚未標記的群組。 v2新增 R-bs 並修正標籤 (CVE-2025-68735)

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

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

  - bpf修正 __bpf_get_stackid() 中的堆疊圖溢位檢查。Syzkaller 報告複製堆疊追踪資料時在 __bpf_get_stackid() 中有 KASAN slab 超出邊界寫入。此問題會在 perf 追踪包含的堆疊項目數量超過堆疊對應值區可容納的數量時發生進而導致值區資料陣列中的超出邊界寫入。 (CVE-2025-68378)

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

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

  - drm/panel/panel-sitronix-st7701移除 DSI 附加失敗時的面板若 mipi_dsi_attach() 失敗請呼叫 drm_panel_remove() 以避免記憶體洩漏。 (CVE-2022-50750)

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

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

  - perf/x86修正 NULL 事件存取和潛在的 PEBS 記錄遺失問題。當呼叫 intel_pmu_drain_pebs_icl() 排出 PEBS 記錄時可呼叫 perf_event_overflow() 來處理最後的 PEBS 記錄。雖然 perf_event_overflow() 可觸發中斷限制並停止該群組的所有事件如以下呼叫鏈所示。 perf_event_overflow() -> __perf_event_overflow()
    ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() 停止事件的副作用是 cpuc->events[ ] 陣列會清除為 NULL。假設一個群組中有兩個 PEBS 事件 (事件 a 和事件 b)。當 intel_pmu_drain_pebs_icl() 呼叫 perf_event_overflow() 以處理 PEBS 事件 a 的最後 PEBS 記錄時會觸發中斷限制並將事件 a 和事件 b 的所有指標清除為 NULL。然後 intel_pmu_drain_pebs_icl() 嘗試處理事件 b 的最後一個 PEBS 記錄並遇到 NULL 指標存取。為避免此問題請將 cpuc->events[] 清除從 x86_pmu_stop() 移至 x86_pmu_del()。這是安全的因為在存取來自 cpuc->events[] 的事件指標之前一律會檢查 cpuc->active_mask 或 cpuc->pebs_enabled。 (CVE-2025-68375)

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

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

  - canj1939移動 j1939_sk_errqueue() 以防止鎖死。此認可可解決在特定情況下可能發生的鎖死情況例如在接收網路中斷事件時執行資料 TP/ETP 傳輸和訂閱錯誤佇列時。此鎖死涉及下列順序的鎖定3 j1939_session_list_lock -> active_session_list_lock j1939_session_activate ...
    j1939_sk_queue_activate_next -> sk_session_queue_lock ... j1939_xtp_rx_eoma_one 2 j1939_sk_queue_drop_all
    -> sk_session_queue_lock ... j1939_sk_netdev_event_netdown -> j1939_socks_lock j1939_netdev_notify 1 j1939_sk_errqueue -> j1939_socks_lock __j1939_session_cancel -> active_session_list_lock j1939_tp_rxtimer CPU0 CPU1 ---- ---- lock(&priv-active)_session_list_lock() lock(&jsk->sk_session_queue_lock);
    lock(&priv->active_session_list_lock); lock(&priv->j1939_socks_lock);在此認可中實作的解決方案是將 j1939_sk_errqueue() 呼叫移出 active_session_list_lock 內容藉此防止鎖死情況。 (CVE-2023-54152)

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

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

  - Regulatorstm32-pwr修正 of_iomap 洩漏 Smatch 報告 drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() 警告 of_iomap() 的「基礎」未在第 151,166 行發布。在 stm32_pwr_regulator_probe() 中當 devm_kzalloc() 無法配置記憶體或 devm_regulator_register() 無法註冊新的調節器裝置時不會釋放基底可能造成洩漏。若要修正此問題請將 of_iomap() 取代為 devm_platform_ioremap_resource()。 devm_platform_ioremap_resource() 是一個適用於 平台裝置的專用函式。無論探查函式成功與否它都允許自動釋放「base」。此外使用 IS_ERR(base) 而非 !base因為 devm_platform_ioremap_resource() 的傳回值可以是重新對應記憶體的指標也可以是 ERR_PTR() 編碼的錯誤碼 (若作業失敗)。 (CVE-2023-54097)

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

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

  - fs/ntfs3使用前初始化配置的記憶體 KMSAN 報告偵測到多個未初始化的值- KMSANntfs_read_hdr 中的 uninit-value (3) - KMSANbcmp 中的 uninit-value (3) 記憶體是由
    __getname()其為 kmem_cache_alloc() 的包裝函式。此記憶體在正確清除之前已使用。
    將 kmem_cache_alloc() 變更為 kmem_cache_zalloc()以便在使用前正確配置並清除記憶體。
    (CVE-2025-68365)

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

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

  - mshv修正建立記憶體區域重疊檢查目前的檢查不正確它只會檢查區域的開頭或結尾是否在現有區域內。這不會將指定區域的使用者空間指定在現有區域之前且結束於現有區域之後。針對每個區域將邏輯變更為針對 gfns 和 uaddrs 進行範圍交集檢查。移除不再使用的 mshv_partition_region_by_uaddr()。 (CVE-2025-68743)

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

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

  - netphyxgmiitorgmii修正 xgmiitorgmii_probe of_phy_find_device() 傳回參照計數增加的裝置節點中的參照計數洩漏。不再需要時呼叫 put_device() 將其釋放。 (CVE-2022-50777)

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

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

  - scsi: qla2xxx: 修正 purex 項目的不當釋放。在 qla2xxx_process_purls_iocb() 中項目是透過 qla27xx_copy_multiple_pkt() 配置而其內部會呼叫 qla24xx_alloc_purex_item()。qla24xx_alloc_purex_item() 函式可能會針對小型配置從各轉接器集區傳回預先配置的項目而非以 kzalloc() 動態配置記憶體。qla2xxx_process_purls_iocb() 中的錯誤處理路徑會不正確地使用 kfree() 來釋放項目。如果項目來自預先配置的集區則呼叫其上的 kfree() 錯誤會導致記憶體損毀。透過使用正確的解除配置函式 qla24xx_free_purex_item() 來修正此問題該函式會正確處理動態配置和預先配置的項目。 (CVE-2025-68741)

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

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

  - bpf更新 [lru_,]percpu_hash 對應時釋放特殊欄位。由於 [lru_,]percpu_hash 對應支援 BPF_KPTR_{REF,PERCPU}因此「pcpu_copy_value()」中的「bpf_obj_free_fields()」遺漏呼叫可造成 BPF_KPTR_ 參照的記憶體保留的 {REF,PERCPU} 欄位直到釋放地圖為止。透過呼叫「pcpu_copy_value()」中「copy_map_value[,_long]()」之後的「bpf_obj_free_fields()」來修正此問題。 (CVE-2025-68744)

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

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

  - 雜項ocxl修正 afu_ioctl() 中可能的 refcount 洩漏。ocxl_irq_set_handler 失敗時需要呼叫 eventfd_ctx_put 來放置 eventfd_ctx_fdget 取得的 refcount。 (CVE-2022-50742)

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

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

  - fs/ntfs3新增 inode 作業的 null 指標檢查這會針對讀取 Root 目錄 MFT 記錄後傳回的 inode i_op 指標新增功能健全檢查。我們應該在嘗試建立 root dentry 之前檢查 i_op 是否有效否則我們可能會在掛載具有奇怪 Root 目錄 MFT 記錄的影像時遇到 NPD。 [ 114.484325] 錯誤核心 NULL 指標解除參照、位址0000000000000008 [114.484811] #PF核心模式中的監督讀取存取 [ 114.485084] #PFerror_code(0x0000) - 不存在頁面 [ 114.485606] PGD 0 P4D 0 [ 114.485975] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 114.486570] CPU: 0 PID: 237 Comm: mount 污染GB 6.0.0-rc4 #28 [ 114.486977] 硬體名稱QEMU Standard PC ( i440FX + PIIX, 1996)、BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 114.488169] RIP
    0010:d_flags_for_inode+0xe0/0x110 [ 114.488816] 程式碼24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 20 8 9 8 e8 60 241 [ 114.490326] RSP
    0018:ffff8880065e7aa8 EFLAGS00000296 [ 114.490695] RAX0000000000000001 RBXffff888008ccd750 RCX
    ffffffff84af2aea [ 114.490986] RDX 0000000000000001 RSI 0000000000000008 RDI ffffffff87abd020 [114.491364] RBP ffff8880065e7ac8 R080000000000000001 R09705 [ffffb fff0f 114.491675] 5 []a [] 5 fffffb fff0f] R105
    ffffffff87abd027 R11fffffffff0f57a04 R120000000000000000 [ 114.491954] R130000000000000008 R14
     R150000000000000000  : ffff888008ccd750 [ 114.492397] FS: 00007fdc8a627e40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 114.492797] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 114.493150] CR2:
    0000000000000008 CR300000000013ba000 CR400000000000006f0 [ 114.493671] 呼叫追踪 [ 114.493890] <TASK> [ 114.494075] __d_instantiate+0x24/0x1c0 [ 114.494505] d_instantiate.part.0+0x35/0x50 [ 114.494754x] d_instantiate++0 [[]3 ] 0x80 [ 114.494998] ntfs_fill_super+0x1232/0x1b50 [ 114.495260] ? put_ntfs+0x1d0/0x1d0 [114.495499] ? vsprintf+0x20/0x20 [ 114.495723] ? set_blocksize+0x95/0x150 [ 114.495964] get_tree_bdev+0x232/0x370 [ 114.496272] put_ntfs+0x1d0/0x1d0 [ 114.496502] ntfs_fs_get_tree+0x15/0x20 [114.496859] vfs_get_tree+0x4c/0x130 [ 114.497099] path_mount+0x654/0xfe0 [ 114.497507] ? putname+0x80/0xa0 [ 114.497933] ? finish_automount+0x2e0/0x2e0 [ 114.498362] ? putname+0x80/0xa0 [ 114.498571] ? kmem_cache_free+0x1c4/0x440 [ 114.498819] ? putname+0x80/0xa0 [ 114.499069] do_mount+0xd6/0xf0 [114.499343] ? path_mount+0xfe0/0xfe0 [ 114.499683] ? __kasan_check_write+0x14/0x20 [ 114.500133]
    __x64_sys_mount+0xca/0x110 [ 114.500592] do_syscall_64+0x3b/0x90 [ 114.500930] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 114.501294] RIP 0033:0x7fdc898e948a [ 114.501542] 代碼48 8b 0d 11 fa 2a 001f7 d8648 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 114.502716] RSP: 002b:00007ffd793e58f8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [114.503175] RAX: ffffffffffffffda RBX0000564b2228f060 RCX00007fdc898e948a [ 114.503588] RDX
    0000564b2228f260 RSI0000564b2228f2e0 RDI 0000564b22297ce0 [ 114.504925] RBP 0000000000000000 R08
    0000564b2228f280 R090000000000000020 [ 114.505484] R1000000000c0ed0000 R110000000000000202 R12
    0000564b22297ce0 [ 114.505823] R13: 0000564b2228f260 R140000000000000000 R1500000000ffffffff [114.506562] </TASK> [ 114.506887] 連結至的模組[ [] ] ] ] 連結於 CR2 的模組 [ 114.507648] ] ] 000000000000008 [ 114.508884]
    ---[ end trace 0000000000000000 ]--- [ 114.509675] RIP 0010:d_flags_for_inode+0xe0/0x110 [ 114.510140] 代碼24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 20 49 8d 7e 08 e8 60 241 [ 114.511762] RSP0018:ffff8880065e7aa8 EFLAGS00000296 [ 114.512401] RAX
    0000000000000001 RBXffff888008ccd750 RCXffffffff84af2aea [ 114.51 ---truncated--- (CVE-2022-50739)

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

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

  - erofs限制檔案支援掛載的 fs 堆疊層級否則可能會造成核心堆疊溢位 (例如EROFS 掛載本身)。 (CVE-2025-68361)

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

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

  - accel/ivpu修正解除系結 BO 時的爭用情形。修正當 ivpu_gem_bo_free() 在 BO 取消對應之前從 BO 清單中移除 BO 時出現的「Memory manager not clean during takedown」警告。然後 file_priv_unbind() 在內容終止期間觸發 drm_mm_takedown() 中的警告。以 bo_list_lock 保護取消對應序列確保 BO 在從清單中移除時始終完全取消對應。如此可確保 BO 在內容終止時完全取消對應或是出現在清單上之後由 file_priv_unbind() 取消對應。 (CVE-2025-68749)

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

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

  - ALSA: mts64修正 snd_mts64_interrupt 中可能的 null-ptr-defer 我在 qemu 平台上執行下列測試時得到一個 null-ptr-defer 錯誤報告進行 defconfig 和 CONFIG_PARPORT=m、CONFIG_PARPORT_PC=m、CONFIG_SND_MTS64=m 那麼製作測試指令碼cat>test_mod1.sh<
    syzkaller:~# ./test_mod.sh snd_mts64snd_mts64.0 探查失敗並出現錯誤 -5 modprobe 錯誤無法插入「snd_mts64」無此類裝置錯誤核心 NULL 指標解除參照、位址000000000000000 #PF
    核心模式中的監督寫入存取錯誤_code(0x0002) - 不存在頁面 PGD 0 P4D 0 Oops0002 [#1] PREEMPT SMP PTI CPU0 PID205 通訊modprobe 未受污染的 6.1.0-rc8-00588 -g76dcd734eca2 #6 呼叫追踪 <IRQ> snd_mts64_interrupt+0x24/0xa0 [snd_mts64] parport_irq_handler+0x37/0x50 [parport]
    __handle_irq_event_percpu+0x39/0x190 handle_irq_event_percpu+0xa/0x30 handle_irq_event+0x2f/0x50 handle_edge_irq+0x99/0x1b0 __common_interrupt+0x5d/0x100 common_interrupt+0xa0/0xc0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30 parport_claim+0xbd/ 0x230 [parport] snd_mts64_probe+0x14a/0x465 [snd_mts64] platform_probe+0x3f/0xa0 emerge_probe+0x129/0x2c0
    __driver_probe_device+0x6d/0xc0 driver_probe_device+0x1a/0xa0 __device_attach_driver+0x7a/0xb0 bus_for_each_drv+0x62/0xb0 __device_attach+0xe4/0x180 bus_probe_device+0x82/0xa0 device_add+0x550/0x920 platform_device_add+0x106/0x220 snd_mts64_attach+0x2e/0x80 [snd_mts64] port_check+ 0x14/0x20 [parport] bus_for_each_dev+0x6e/0xc0 __parport_register_driver+0x7c/0xb0 [parport] snd_mts64_module_init+0x31/0x1000 [snd_mts64] do_one_initcall+0x3c/0x1f0 do_init_module+0x46/0x1c6 load_1module+0x1d
    __do_sys_finit_module+0xa2/0xf0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> 核心錯誤 - 未同步：中斷重新開機中發生嚴重例外狀況 1 秒後。mts 在中斷期間未初始化我們新增了 mts 檢查來修正此錯誤。 (CVE-2022-50773)

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

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

  - HSIssi_protocol修正 ssip_pn_open() 中潛在的資源洩漏問題 ssip_pn_open() 使用 hsi_claim_port() 宣告 HSI 用戶端的連接埠。當 hsi_register_port_event() 發生錯誤並傳回負值時應使用 hsi_release_port() 釋放 HSI 用戶端的連接埠。在 hsi_register_port_event() 失敗時呼叫 hsi_release_port() 以修正此問題。 (CVE-2022-50708)

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

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

  - nbd延遲在 recv_work 中放置的組態執行 NBD_CLEAR_SOCK 和 NBD_CMD_RECONFIGURE 時recv_work 中有一個 uaf 問題nbd_genl_connect // conf_ref=2 (連線和 recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (觸發 recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (nbd
    在通知 waiter 之前呼叫 nbd_config_put()) 已將 nbd_config_put() 在喚醒 recv_work 中的 waiter 之前先執行以確保 nbd_start_device_ioctl() 在 nbd->task_recv 仍未清除時不會被喚醒。不過在 nbd_start_device_ioctl() 中它被喚醒之後會明確呼叫 flush_workqueue() 以確保完成所有目前的工作。因此不需要在喚醒前移動設定。將 nbd_config_put() 移至 recv_work 的結尾以便在背景工作執行緒的整個存留期保留參照。這可確保當 recv_work 仍在執行時無法釋放組態即使清除 + 重新設定交錯也是如此。此外我們不需要擔心 recv_work 中斷最後一個 nbd_put (會造成鎖死)path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT)connect // nbd_refs=1 (觸發 recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work 完成 nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (無 NBD_CFLAG_DESTROY_ON_DISCONNECT 的 netlink): 連線 // nbd_refs=2 (觸發 recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCKconf_ =2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-one2daec488c57 (nbd修正 hangtask when nbd_config_put) (CVE-2025-68372)

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

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

  - drm/panthor修正核心 BO VA 節點上的 UAF 如果 MMU 當機panthor_vm_unmap_range() 可能會傳回錯誤。我們預期頁面表格仍會更新如果 MMU 已封鎖則 GPU 的其餘部分也應封鎖因此不會將存取實體記憶體的風險傳回系統 (目前的程式碼無論如何都不會涵蓋此問題) 。繼續執行其餘的清理作業而非結束並讓 va_node 插入 drm_mm這會導致在從 drm_mm 樹狀結構移除其他相鄰節點時發生 UAF。 (CVE-2025-68747)

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

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

  - blk-cgroup當移除 blkg->q_node 時保留 queue_lock。從 blkg_free_workfn() 中移除 q->blkg_list 中的 blkg 時必須保留 queue_lock否則所有類型的錯誤 (清單損毀、硬鎖定等) 都會從 blkg_destroy_all() 觸發。 (CVE-2023-54088)

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

ID	名稱	嚴重性
279796	Linux Distros 未修補的弱點：CVE-2023-54047	medium
279795	Linux Distros 未修補的弱點：CVE-2023-54002	medium
279794	Linux Distros 未修補的弱點：CVE-2025-68727	high
279793	Linux Distros 未修補的弱點：CVE-2022-50772	medium
279792	Linux Distros 未修補的弱點：CVE-2025-68726	high
279791	Linux Distros 未修補的弱點：CVE-2025-68348	medium
279790	Linux Distros 未修補的弱點：CVE-2022-50751	medium
279789	Linux Distros 未修補的弱點：CVE-2023-54120	medium
279788	Linux Distros 未修補的弱點：CVE-2023-54136	high
279787	Linux Distros 未修補的弱點：CVE-2025-68354	high
279785	Linux Distros 未修補的弱點：CVE-2022-50704	medium
279784	Linux Distros 未修補的弱點：CVE-2025-68724	high
279782	Linux Distros 未修補的弱點：CVE-2023-54086	medium
279781	Linux Distros 未修補的弱點：CVE-2023-54035	high
279780	Linux Distros 未修補的弱點：CVE-2023-54157	medium
279779	Linux Distros 未修補的弱點：CVE-2023-54085	medium
279778	Linux Distros 未修補的弱點：CVE-2023-54116	high
279777	Linux Distros 未修補的弱點：CVE-2022-50741	medium
279776	Linux Distros 未修補的弱點：CVE-2022-50744	medium
279775	Linux Distros 未修補的弱點：CVE-2025-68349	high
279774	Linux Distros 未修補的弱點：CVE-2023-54134	medium
279773	Linux Distros 未修補的弱點：CVE-2025-14934	high
279772	Linux Distros 未修補的弱點：CVE-2025-68344	high
279771	Linux Distros 未修補的弱點：CVE-2023-53867	high
279770	Linux Distros 未修補的弱點：CVE-2023-54153	medium
279769	Linux Distros 未修補的弱點：CVE-2025-68368	medium
279768	Linux Distros 未修補的弱點：CVE-2025-68358	medium
279767	Linux Distros 未修補的弱點：CVE-2022-50749	high
279766	Linux Distros 未修補的弱點：CVE-2023-54083	high
279765	Linux Distros 未修補的弱點：CVE-2022-50720	medium
279764	Linux Distros 未修補的弱點：CVE-2025-68735	high
279763	Linux Distros 未修補的弱點：CVE-2025-68378	high
279762	Linux Distros 未修補的弱點：CVE-2022-50750	medium
279761	Linux Distros 未修補的弱點：CVE-2025-68375	medium
279760	Linux Distros 未修補的弱點：CVE-2023-54152	medium
279759	Linux Distros 未修補的弱點：CVE-2023-54097	medium
279758	Linux Distros 未修補的弱點：CVE-2025-68365	medium
279757	Linux Distros 未修補的弱點：CVE-2025-68743	high
279756	Linux Distros 未修補的弱點：CVE-2022-50777	medium
279754	Linux Distros 未修補的弱點：CVE-2025-68741	medium
279753	Linux Distros 未修補的弱點：CVE-2025-68744	high
279752	Linux Distros 未修補的弱點：CVE-2022-50742	high
279751	Linux Distros 未修補的弱點：CVE-2022-50739	high
279750	Linux Distros 未修補的弱點：CVE-2025-68361	high
279749	Linux Distros 未修補的弱點：CVE-2025-68749	medium
279748	Linux Distros 未修補的弱點：CVE-2022-50773	medium
279747	Linux Distros 未修補的弱點：CVE-2022-50708	high
279746	Linux Distros 未修補的弱點：CVE-2025-68372	high
279745	Linux Distros 未修補的弱點：CVE-2025-68747	high
279744	Linux Distros 未修補的弱點：CVE-2023-54088	high

偵測

Nessus 的 Misc. 系列

medium

medium

high

medium

high

medium

medium

medium

high

high

medium

high

medium

high

medium

medium

high

medium

medium

high

medium

high

high

high

medium

medium

medium

high

high

medium

high

high

medium

medium

medium

medium

medium

high

medium

medium

high

high

high

high

medium

medium

high

high

high

high