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

  - 已解決 Linux 核心中的下列弱點：power: supply: bq25890: Fix external_power_changed race bq25890_charger_external_power_changed() dereferences bq->charger, which gets sets in bq25890_power_supply_init() like this: bq->charger = devm_power_supply_register(bq->dev, &bq->desc, &psy_cfg); As soon as devm_power_supply_register() has called device_add() the external_power_changed callback can get called. So there is a window where bq25890_charger_external_power_changed() may get called while bq->charger has not been set yet leading to a NULL pointer dereference. This race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f when the cht_wcove_pwrsrc (extcon) power_supply is done with detecting the connected charger-type which happens to exactly hit the small window: BUG: kernel NULL pointer dereference, address: 0000000000000018 <snip> RIP:
    0010:__power_supply_is_supplied_by+0xb/0xb0 <snip> Call Trace: <TASK>
    __power_supply_get_supplier_property+0x19/0x50 class_for_each_device+0xb1/0xe0 power_supply_get_property_from_supplier+0x2e/0x50 bq25890_charger_external_power_changed+0x38/0x1b0 [bq25890_charger] __power_supply_changed_work+0x30/0x40 class_for_each_device+0xb1/0xe0 power_supply_changed_work+0x5f/0xe0 <snip> Fixing this is easy. The external_power_changed callback gets passed the power_supply which will eventually get stored in bq->charger, so bq25890_charger_external_power_changed() can simply directly use the passed in psy argument which is always valid. (CVE-2023-53166)

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

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

  - drm/sti修正 sti_{dvo,hda,hdmi}_connector_mode_valid() 的傳回類型 透過 clang 的核心控制流程完整性 (kCFI, CONFIG_CFI_CLANG) 間接呼叫目標會根據預期的函式指標原型進行驗證以確保呼叫目標為有效協助減輕 ROP 攻擊。如果不同則執行時會發生失敗其表現形式為核心錯誤或執行緒遭到終止。clang 中的一個建議警告旨在於編譯時擷取這些警告其顯示：
    drivers/gpu/drm/sti/sti_hda.c:637:16錯誤使用 'int (struct drm_connector * , struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hda_connector_mode_valid^~~~~~~~~~~ ~~~ drivers/gpu/drm/sti/sti_dvo.c:376:16錯誤正在使用「int 類型的運算式」初始化「enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)」不相容的函式指標類型(struct drm_connector *, struct drm_display_mode *)」 [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_dvo_connector_mode_valid^~~~~~ ~ ~ ~ ~ ~ ~ ~ ~ ~~~~~~ drivers/gpu/drm/sti/sti_hdmi.c:1035:16錯誤不相容的函式指標類型正在使用運算式初始化「enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)」類型為 'int (struct drm_connector *, struct drm_display_mode *)」 [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hdmi_connector_mode_valid, ^~~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~~ 「struct drm_connector_helper_funcs」中的 ->mode_valid() 預期傳回類型為「enum drm_mode_status」而非「int」。調整 sti_{dvo,hda,hdmi}_connector_mode_valid() 的傳回類型以符合原型的 以解決警告和 CFI 失敗。 (CVE-2022-50261)

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

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

  - fs/smb修正不一致的 refcnt 更新。在「smb2_compound_op」中發現可能不一致的 refcount 更新。此類不一致的更新可導致可能的資源洩漏。為什麼這可能是錯誤 1. 在函式的註解區段中明確指出呼叫此函式後應中斷 `cfile` 參照。 2. 所有控制流程路徑都會檢查併中斷 `cfile` 的參照 (已修補的路徑除外)。 3. 如果在
    傳回 -ENOMEM。為修正此錯誤已新增額外的 goto 標籤輸出以確保一律遵循清理邏輯。由於此問題是由 `vars` 的配置失敗所造成因此可以安全地忽略 labelfinished 和 out 之間的清理邏輯。根據 `is_replayable_error` 函式的定義 -ENOMEM 的錯誤碼無法復原。因此重播邏輯也會遭到忽略。 (CVE-2025-39819)

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

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

  - xfs不將 ENODATA 磁碟錯誤傳播到 xattr 程式碼中。ENODATA (即 ENOATTR) 在 xfs xattr 程式碼中具有非常特定的意義。亦即找不到要求的屬性名稱。不過磁碟的中等錯誤也可能傳回 ENODATA。此中等錯誤充其量只是因為找不到屬性而逸出到使用者空間但實際上卻是 IO (磁碟) 錯誤。在最壞的情況下我們可能會在 xfs_attr_leaf_get() 中發生 oops error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) {xfs_trans_brelse(args->trans, bp);傳回錯誤因為磁碟中的 ENODATA/ENOATTR 錯誤為我們留下 null bp而 xfs_trans_brelse 之後會對其進行 null 解除參照。如同清單中所討論的我們確實需要修改較低層級的 IO 函式以設陷所有磁碟錯誤並確保不會讓此類獨特錯誤洩漏到較高層 xfs 函式中許多此類錯誤應重新對應至 EIO。不過此修補程式可直接解決 xattr 程式碼中報告的錯誤而且應該可以安全地反向移植至穩定的核心。稍後可能會發布範圍更大的修補程式以處理較低層級的更多獨特錯誤。(請注意在 07120f1abdff 之前我們並未發生 oops但我們確實將錯誤的錯誤碼傳回使用者空間。) (CVE-2025-39835)

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

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

  - 已解決 Linux 核心中的下列弱點：f2fs: fix scheduling while atomic in decompression path [ 16.945668][ C0] Call trace: [ 16.945678][ C0] dump_backtrace+0x110/0x204 [16.945706][ C0] dump_stack_lvl+0x84/0xbc [ 16.945735][ C0] __schedule_bug+0xb8/0x1ac [ 16.945756][ C0]
    __schedule+0x724/0xbdc [ 16.945778][ C0] schedule+0x154/0x258 [ 16.945793][ C0] bit_wait_io+0x48/0xa4 [16.945808][ C0] out_of_line_wait_on_bit+0x114/0x198 [ 16.945824][ C0] __sync_dirty_buffer+0x1f8/0x2e8 [16.945853][ C0] __f2fs_commit_super+0x140/0x1f4 [ 16.945881][ C0] f2fs_commit_super+0x110/0x28c [16.945898][ C0] f2fs_handle_error+0x1f4/0x2f4 [ 16.945917][ C0] f2fs_decompress_cluster+0xc4/0x450 [16.945942][ C0] f2fs_end_read_compressed_page+0xc0/0xfc [ 16.945959][ C0] f2fs_handle_step_decompress+0x118/0x1cc [ 16.945978][ C0] f2fs_read_end_io+0x168/0x2b0 [ 16.945993][ C0] bio_endio+0x25c/0x2c8 [ 16.946015][ C0] dm_io_dec_pending+0x3e8/0x57c [ 16.946052][ C0] clone_endio+0x134/0x254 [ 16.946069][ C0] bio_endio+0x25c/0x2c8 [ 16.946084][ C0] blk_update_request+0x1d4/0x478 [ 16.946103][ C0] scsi_end_request+0x38/0x4cc [ 16.946129][ C0] scsi_io_completion+0x94/0x184 [ 16.946147][ C0] scsi_finish_command+0xe8/0x154 [ 16.946164][ C0] scsi_complete+0x90/0x1d8 [ 16.946181][ C0] blk_done_softirq+0xa4/0x11c [ 16.946198][ C0]
    _stext+0x184/0x614 [ 16.946214][ C0] __irq_exit_rcu+0x78/0x144 [ 16.946234][ C0] handle_domain_irq+0xd4/0x154 [ 16.946260][ C0] gic_handle_irq.33881+0x5c/0x27c [ 16.946281][ C0] call_on_irq_stack+0x40/0x70 [ 16.946298][ C0] do_interrupt_handler+0x48/0xa4 [ 16.946313][ C0] el1_interrupt+0x38/0x68 [ 16.946346][ C0] el1h_64_irq_handler+0x20/0x30 [ 16.946362][ C0] el1h_64_irq+0x78/0x7c [ 16.946377][ C0] finish_task_switch+0xc8/0x3d8 [ 16.946394][ C0]
    __schedule+0x600/0xbdc [ 16.946408][ C0] preempt_schedule_common+0x34/0x5c [ 16.946423][ C0] preempt_schedule+0x44/0x48 [ 16.946438][ C0] process_one_work+0x30c/0x550 [ 16.946456][ C0] worker_thread+0x414/0x8bc [ 16.946472][ C0] kthread+0x16c/0x1e0 [ 16.946486][ C0] ret_from_fork+0x10/0x20 (CVE-2023-53262)

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

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

  - 已解決 Linux 核心中的下列弱點：PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the device yet), doing a VM hibernation triggers a panic in hv_pci_restore_msi_msg() -> msi_lock_descs(&pdev->dev), because pdev->dev.msi.data is still NULL. Avoid the panic by checking if MSI-X/MSI is enabled. (CVE-2023-53175)

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

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

  - bnxt_en修正在 ifdown 期間 FW 資源變更時的記憶體損毀問題bnxt_set_dflt_rings() 會假設一律會在建立任何 TC 之前呼叫它。因此它不會將 bp->num_tc 納入考量並假設它一律為 0 或 1。在 FW 資源或功能變更的情況下FW 會傳回 bnxt_hwrm_if_change() 中的旗標這會造成驅動程式重新初始化並呼叫 bnxt_cancel_reservations ()。這會導致 bnxt_init_dflt_ring_mode() 呼叫 bnxt_set_dflt_rings()且 bp->num_tc 可能大於 1。這會造成 bp->tx_ring[] 的大小過小並造成 bnxt_alloc_cp_rings() 中的記憶體損毀。透過上述程式碼路徑中的 bp->num_tc 正確縮放 TX 環來修正此問題。新增 2 個協助程式函式以判斷 bp->tx_nr_rings 和 bp->tx_nr_rings_per_tc。 (CVE-2025-39810)

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

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

  - blk-mq修正 blk_mq_elv_switch_none 中 q->elevator 的 NULL 解除參照。抓取 q->sysfs_lock 之後q->elevator 可能會因為移位機切換而變成 NULL。透過鎖定檢查來修正 q->elevator 的 NULL 解除參照。 (CVE-2023-53292)

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

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

  - 已解決 Linux 核心中的下列弱點：fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds Commit 56124d6c87fd (fsverity: support enabling with tree block size < PAGE_SIZE) changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read the file's data, instead of direct pagecache accesses.
    An unintended consequence of this is that the 'WARN_ON_ONCE(!(file->f_mode & FMODE_READ))' in
    __kernel_read() became reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called on a fd opened with access mode 3, which means ioctl access only. Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But ioctl-only fds are a weird Linux extension that is rarely used and that few people even know about. (The documentation for FS_IOC_ENABLE_VERITY even specifically says it requires O_RDONLY.) It's probably not worthwhile to make the ioctl internally open a new fd just to handle this case. Thus, just reject the ioctl on such fds for now. (CVE-2023-53172)

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

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

  - udf寫入內嵌檔案失敗時不更新檔案長度。當寫入內嵌檔案失敗 (或僅發生部分)我們仍會按照整個寫入成功的方式更新內嵌資料的長度。修正內嵌資料長度的更新只有在寫入成功時才會發生。 (CVE-2023-53295)

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

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

  - USBchipidea修正使用 debugfs_lookup() 時發生的記憶體洩漏。呼叫 debugfs_lookup() 時結果必須有呼叫 dput() 否則記憶體會隨著時間推移而洩漏。為使事情變得更簡單只要呼叫 debugfs_lookup_and_remove() 而不是它會立即處理所有邏輯。 (CVE-2023-53334)

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

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

  - 已解決 Linux 核心中的下列弱點：phy: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe() The size of array 'priv->ports[]' is INNO_PHY_PORT_NUM. In the for loop, 'i' is used as the index for array 'priv->ports[]' with a check (i > INNO_PHY_PORT_NUM) which indicates that INNO_PHY_PORT_NUM is allowed value for 'i' in the same loop. This > comparison needs to be changed to >=, otherwise it potentially leads to an out of bounds write on the next iteration through the loop (CVE-2023-53238)

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

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

  - scsiqla2xxx移除未使用的 nvme_ls_waitq 等待佇列當 qla2x00_start_sp(sp) 傳回錯誤碼 EGAIN 且系統在未初始化的等待佇列 sp->nvme_ls_waitq 中呼叫 wake_up 時系統當機。 qla2xxx [0000:37:00.1]-2121:5idx=0 時傳回 ffff8ae2c0513400 的現有 qpair qla2xxx [0000:37:00.1]-700e:5qla2x00_start_sp failed = 11 錯誤無法處理 00000000000000 PGD 的核心 NULL 指標解除參照0 P4D 0 Oops0000 [#1] SMP NOPTI 硬體名稱HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10、BIOS U32 2021 年 9 月 3 日 工作佇列nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP
    0010:__wake_up_common+0x4c/0x190 RSP0018:ffff95f3e0cb7cd0 EFLAGS00010086 RAX0000000000000000 RBX
    ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11:
     R12ffff95f3e0cb7a60  : ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR400000000007706e0 DR0
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc] 移除未使用的 nvme_ls_waitq 等待佇列。 nvme_ls_waitq 邏輯先前已在下方標記為「修正」的提交中移除。 (CVE-2023-53280)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/msm/dp: fix bridge lifetime Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP bridges, previously allocated bridges will leak on probe deferral. Fix this by amending the DP parser interface and tying the lifetime of the bridge device to the DRM device rather than DP platform device. Patchwork:
    https://patchwork.freedesktop.org/patch/502667/ (CVE-2022-50292)

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

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

  - 已解決 Linux 核心中的下列弱點：kcm: annotate data-races around kcm->rx_psock kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. We do the same for kcm->rx_wait in the following patch. syzbot reported: BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:
    unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313 kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373
    __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0: kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline]
    __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161
    ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline]
    __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffff88812971ce00 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 (CVE-2022-50291)

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

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

  - Layout 元件中的同源原則繞過。此弱點已在 Firefox 143、Firefox ESR 140.3、Thunderbird 143 和 Thunderbird 140.3中修正。 (CVE-2025-10529)

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

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

  - net/mlx5: HWS修正 hws_action_get_shared_stc_nic 錯誤流程中的記憶體洩漏。提供無效的 stc_type 時函式會為 shared_stc 配置記憶體但在未釋放該記憶體的情況下跳至 unlock_and_out進而造成記憶體洩漏。透過跳至 free_shared_stc 標籤以確保適當清理來修正。
    (CVE-2025-39834)

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

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

  - btrfs修正變成未使用的新區塊群組之釋放後使用如果某項工作建立了新區塊群組且該區塊群組在我們完成建立之前處於未使用狀態則在 btrfs_create_pending_block_groups()則當針對我們假設該區塊群組目前位於要回收的區塊群組清單中則將其移出新區塊群組清單而移至未使用的區塊群組清單。這會造成兩個後果1) 我們將其移出與目前交易相關的新區塊群組清單。因此區塊群組的建立並未完成且如果因為 bg 未使用而嘗試刪除該 bg我們將不會在範圍樹狀結構 (或新的區塊群組樹狀結構) 中尋找區塊群組項目也不會在裝置樹狀結構中找到其裝置範圍項目等等。導致因遺漏項目而導致刪除作業失敗2) 將區塊群組移至未使用區塊群組清單時並未增加其參照計數因為我們假設區塊群組列於要回收的區塊群組清單中而在此情況下其已擁有更正參照計數。不過封鎖群組位於新封鎖群組的清單在此情況下系統不會採用額外參照因為這是目前工作的本機項目。這會導致之後在從未使用清單中移除區塊群組時進行額外的參照計數遞減最終導致參照計數為 0。從 fstests 執行 generic/297 時會擷取第二種情況進而產生下列宣告失敗和堆疊追踪[589.559] 宣告失敗refcount_read(&block_group->refs) == 1在 fs/btrfs/block-group.c:4299 中 [589.559]
    ------------[cut here ]------------ [589.559] fs/btrfs/block-group.c:4299! 的核心錯誤[589.560] 無效 opcode0000 [#1] PREEMPT SMP PTI [589.560] CPU8 PID 2819134 Commumount 污染GW 6.4.0-rc6-btrfs-next-134+ #1 [589.560] 硬體nameQEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [589.560] RIP
    0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.561] 代碼68 62 da c0 (...) [589.561] RSP
    0018:ffffa55a8c3b3d98 EFLAGS00010246 [589.561] RAX0000000000000058 RBXffff8f030d7f2000 RCX
    0000000000000000 [589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff [589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50 [589.562] R10: 0000000000000001 R11:
    0000000000000001 R12ffff8f05850b4c00 [589.562] R13ffff8f030d7f2090 R14ffff8f05850b4cd8 R15
    dead000000000100 [589.563] FS: 00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000 [589.563] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [589.563] CR2: 00007f497ff8ec10 CR3:
    0000000271472006 CR40000000000370ee0 [589.563] DR00000000000000000 DR10000000000000000 DR2
    0000000000000000 [589.564] DR30000000000000000 DR600000000fffe0ff0 DR70000000000000400 [589.564] 呼叫追踪 [589.564] [] <TASK> [589.565] __die_body+0x1b/0x60 [589.565] ? die+0x39/0x60 [589.565] ? do_trap+0xeb/0x110 [589.565] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.566] do_error_trap+0x6a/0x90 [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.566] exc_invalid_op+0x4e/0x70 [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] asm_exc_invalid_op+0x16/0x20 [589.567] btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] close_ctree+0x35d/0x560 [btrfs] [589.568] ? fsnotify_sb_delete+0x13e/0x1d0 [589.568] ? dispose_list+0x3a/0x50 [589.568] ? evict_inodes+0x151/0x1a0 [589.568] generic_shutdown_super+0x73/0x1a0 [589.569] kill_anon_super+0x14/0x30 [589.569] btrfs_kill_super+0x12/0x20 [btrfs] [589.569] deactivate_locked ---truncated--- (CVE-2023-53187)

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

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

  - 在 2.7.2 之前的 Expat 中libexpat 允許攻擊者透過提交進行剖析的小文件觸發大量動態記憶體配置。 (CVE-2025-59375)

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

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

  - 已解決 Linux 核心中的下列弱點：ASoC: fsl_mqs: move of_node_put() to the correct location of_node_put() should have been done directly after mqs_priv->regmap = syscon_node_to_regmap(gpr_np); otherwise it creates a reference leak on the success path. To fix this, of_node_put() is moved to the correct location, and change all the gotos to direct returns.
    (CVE-2023-53268)

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

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

  - scsilpfc修正 sysfs 韌體寫入期間的釋放後使用 KFENCE 違規。在 sysfs 韌體寫入處理程序期間系統會從 lpfc_wr_object() 常式記錄釋放後使用讀取警告
    lpfc_wr_object+0x235/0x310 中的釋放後使用讀取 [lpfc] 0x0000000000cf164d 的釋放後讀取 (在 kfence-#111中)lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write__firmware.cold+0x206/0x30d [lpfc] lpfc] lpfc+0xli46_request_firmware_updatec_000cf164d /0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The driver accessed wr_object pointer data,此問題會在信箱物件釋放回信箱集區後初始化至信箱承載記憶體中。透過將信箱釋放呼叫移至常式末端來修正以確保我們在釋放後不會參照內部信箱記憶體。 (CVE-2023-53282)

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

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

  - 已解決 Linux 核心中的下列弱點：ext4: don't allow journal inode to have encrypt flag Mounting a filesystem whose journal inode has the encrypt flag causes a NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt' mount option is used. The problem is that when jbd2_journal_init_inode() calls bmap(), it eventually finds its way into ext4_iomap_begin(), which calls fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if the inode is encrypted, then its encryption key must already be set up. That's not the case here, since the journal inode is never opened like a normal file would be. Hence the crash. A reproducer is: mkfs.ext4 -F /dev/vdb debugfs -w /dev/vdb
    -R set_inode_field <8> flags 0x80808 mount /dev/vdb /mnt -o inlinecrypt To fix this, make ext4 consider journal inodes with the encrypt flag to be invalid. (Note, maybe other flags should be rejected on the journal inode too. For now, this is just the minimal fix for the above issue.) I've marked this as fixing the commit that introduced the call to fscrypt_limit_io_blocks(), since that's what made an actual crash start being possible. But this fix could be applied to any version of ext4 that supports the encrypt feature. (CVE-2022-50277)

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

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

  - 範例/bpf修正 hbm 的 run_bpf_prog 中的 fout 洩漏。修正 fopen 執行 fopen但後續 fclose 未執行的 fout。在受影響的分支中fout 會超出範圍。 (CVE-2023-53290)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create We can't simply free the connector after calling drm_connector_init on it. We need to clean up the drm side first. It might not fix all regressions from commit 2b5d1c29f6c4 (drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts), but at least it fixes a memory corruption in error handling related to that commit. (CVE-2023-53263)

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

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

  - 已解決 Linux 核心中的下列弱點：media: hi846: fix usage of pm_runtime_get_if_in_use() pm_runtime_get_if_in_use() does not only return nonzero values when the device is in use, it can return a negative errno too. And especially during resuming from system suspend, when runtime pm is not yet up again, -EAGAIN is being returned, so the subsequent pm_runtime_put() call results in a refcount underflow. Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use().
    (CVE-2023-53177)

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

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

  - ext4修正部分寫入情況下 i_disksize 超過 i_size 的問題。i_disksize 可能會超過 i_size進而觸發警告。 generic_perform_write cooked = iov_iter_copy_from_user_atomic(len) // 複製 < len ext4_da_write_end | ext4_update_i_disksize | new_i_size = pos + 已復制| WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // 更新 i_disksize | generic_write_end | copyed = block_write_end(copyed, len) // copyed = 0 | if (unlikely(copyed < len)) | if (!PageUptodate(page)) |複製的 = 0 | if (pos +copyed > inode->i_size) // 再次傳回 false if (unlikely(copyed == 0)) goto if (unlikely(iov_iter_fault_in_可讀(i, bytes))) { status = -EFAULT;中斷我們在這裡得到的 i_disksize 大於 i_size這可能會在執行 dio: ext4_dio_write_iter iomap_dio_rw __iomap_dio_rw // 傳回錯誤長度未與 512 ext4_handle_inode_extension WARN_ON_ONCE(i_size_read (inode) < EXT4_I(inode)->i_disksize) // Oops 警告
    CPU: 2 PID: 2609 at fs/ext4/file.c:319 CPU: 2 PID: 2609 Comm: aa 未受污染的 6.3.0-rc2 RIP
    0010:ext4_file_write_iter+0xbc7 呼叫追踪vfs_write+0x3b1 ksys_write+0x77 do_syscall_64+0x39 透過在更新 i_disksize 之前更新 'copyed' 值來修正此問題就像 ext4_write_inline_data_end() 一樣。複製器可在下面的 buganizer 連結中找到。 (CVE-2023-53270)

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

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

  - Networking: Cache 元件中的資訊洩漏。此弱點已在 Firefox 143、Firefox ESR 140.3、Thunderbird 143 和 Thunderbird 140.3中修正。 (CVE-2025-10536)

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

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

  - ext4修正 mb_find_extent 中的警告 Syzbot 發現下列問題EXT4-fs警告使用 data=journal 進行掛載會停用延遲配置、dioread_nolock、O_DIRECT 和 fast_commit 支援EXT4-fs (loop0)在唯讀 fs 上發生孤立清理 ------------[ 在此處剪切 ]------------ 警告 CPU: 1 PID: 5067 at fs /ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30 模組連結於 CPU1 PID5067 Commsyz-executor307 未受污染的 6.2.0-rc1-syzkaller #0 硬體名稱 Google Google Compute Engine/Google Compute Engine BIOS Google 10/26/2022 RIP 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869 RSP
    0018:ffffc90003c9e098 EFLAGS: 00010293 RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0 RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040 RBP: 0000000000000040 R08:
     R09ffffffff82405723  : ffffed10053c9402 R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000 R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc FS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307 ext4_mb_regular_allocator+0x1533/0x3860 fs /ext4/mballoc.c:2735 ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605 ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286 ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651 ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864 ext4_bread+0x2a/0x170 fs/ext4/inode.c:920 ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105 write_blk fs/quota/quota_tree.c :64 [內嵌] get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130 do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 do_insert_tree+0x722 /0x1aa0 fs/quota/quota_tree.c:375 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 dq_insert_tree fs/quota/quota_tree.c:401 [內嵌] qtree_ write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420 v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358 dquot_acquire+0x348/0x670 fs/quota/dquot.c:444 ext4_acquire_dquot+0x2dc/0x400 fs/ext4 /super.c:6740 dqget+0x999/0xdc0 fs/quota/dquot.c:914
    __dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492 ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c :5516 [內嵌] ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/ namespace.c:3145 do_mount fs/namespace.c:3488 [內嵌] __do_sys_mount fs/namespace.c:3697 [內嵌] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c 50 [內嵌] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 新增部分除錯資訊
    mb_find_extentmb_find_extent block=41, order=0 need=64 next=0 ex=0/41/1@3735929054 64 64 7 block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 確切地說每個群組有 64 個區塊但是區塊點陣圖顯示至少有 128 個區塊。現在ext4_validate_block_bitmap() 不會檢查無效區塊的點陣圖 (若已設定)。若要解決上述問題請新增如 fsck 在區塊點陣圖結尾填補未設定的檢查。 (CVE-2023-53317)

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

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

  - 已解決 Linux 核心中的下列弱點：crypto: cavium - prevent integer overflow loading firmware The code_length value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly. The ntohl(ucode->code_length) * 2 multiplication can have an integer overflow. (CVE-2022-50330)

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

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

  - RDMA/mlx5損毀 QP/RQ 時傳回韌體結果。之前的版本損毀 QP/RQ 時會忽略韌體損毀函式的結果且不會通知上層有關失敗的資訊。
    這進而可能導致各種問題因為當上層未察覺失敗時它會繼續其作業以為相關 QP/RQ 已成功破壞而實際上並沒有這可能導致出現以下核心 WARN。目前我們會將正確的韌體損毀狀態傳回給上層如果是 RQ 則傳回已能夠處理 RQ 解構失敗的 mlx5_ib_destroy_wq()或者傳回傳回傳回至 destroy_qp_common()(現在會在 qp 時發出警告)損毀失敗。WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse CPU3 PID995 Comm: python3 未受污染的 5.16.0-rc5+ #1 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS rel-1.13.0-0-gf21b5a4aeb02- prebuilt.qemu.org 04/01/2014 RIP
    0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] 代碼41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 ff e 4 85 c0 74 a1 ff e 4 877 0f 0b eb c1 <0f> 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287 RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000 RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI
    ffff888109b101a0 RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009 R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780 R13: ffff888106209750 R14: ffff888100f20660 R15:
    0000000000000000 FS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS
    0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0 DR0
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ib_uverbs_close+0x1a/0x90 [ib_uverbs] __fput+0x82/0x230 task_work_run+0x59/0x90 exit_to_user_mode_prepare+0x138/0x140 syscall_exit_to_user_mode+0x1d/0x50 ?
    __x64_sys_close+0xe/0x40 do_syscall_64+0x4a/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP
    0033:0x7f8be3ae0abb 程式碼03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 0 03 00 00 0 0 <48> [5] 00 0f 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44 RSP002b00007ffdb51909c0 EFLAGS00000293 ORIG_RAX0000000000000003 RAX00000X0000 00000X0000 00000X00000
    0000557bb7f7c020 RCX: 00007f8be3ae0abb RDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005 RBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000293 R120000557bb7fbd5b8 R130000557bb7fbd5a8 R140000000000001000 R150000557bb7f7c020 </TASK> (CVE-2023-53286)

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

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

  - f2fs修正以在復原期間對目的地 blkaddr 進行功能健全檢查如 Wenqing Liu 在 bugzilla 中所報告
    https://bugzilla.kernel.org/show_bug.cgi?id=216456 loop5偵測到容量變更從 0 到 131072 F2FS-fs (loop5)recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): restore_data: ino = 6 (i_size:
    restore) err = 0 F2FS-fs (loop5)recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5)
    restore_data: ino = 6 (i_sizerecover) err = 0 F2FS-fs (loop5): restore_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): restore_data: ino = 6 (i_size: restore) err = 0 F2FS-fs (loop5)點陣圖設定錯誤 blk:5634 ------------[cut here ]------------ 警告CPU 3 PID: 1013 at fs/f2fs/segment.c:2198 RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs] 呼叫追踪 <TASK> f2fs_do_replace_block+0xa98/0x1890 [f2fs] f2fs_replace_block+0xeb/0x180 [f2fs] restore_data+0a96 /0x6ae0 [f2fs] f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/ 0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd 如果我們啟用 CONFIG_F2FS_CHECK_FS 組態則會觸發核心錯誤而非警告。根本原因是在模糊影像中SIT 表格與 inode 對應表格不一致導致在 SIT 表格更新期間觸發此類警告。此修補程式引入新旗標 DATA_GENERIC_ENHANCE_UPDATEw/此旗標資料區塊復原流程可檢查 SIT 表格中的目的地 blkaddr 驗證並略過 f2fs_replace_block() 以避免不一致的狀態。 (CVE-2022-50273)

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

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

  - 在 Podman 中發現一個瑕疵。在 Containerfile 或 Podman 中並未捨棄在 podman 構建期間寫入 RUN --mount=type=bind 掛載的資料。此問題可導致在容器內建立的檔案出現在主機上的暫時版本內容目錄中使建立的檔案可供存取。
    (CVE-2025-4953)

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

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

  - usbcdns3將 cdns 集使用中的部分放在微調鎖定之外。可在繼續處理程序期間為裝置排程因此這不會出現在不可部分完成的作業中。由於 pm_runtime_set_active 會恢復供應商因此請將 set active 置於微調鎖定之外 (其僅用於保護 struct cdns 資料結構否則核心將會報告下列警告: BUG: sleep function call from套用drivers/base/power/) runtime.c1163 in_atomic()1、irqs_disabled()0、non_block 0、pid651、名稱 sh preempt_count 1、預期 0 RCU 巢狀深度 0、預期 0 CPU0 PID 651 Commsh 污染的 G WC 6.1.20 #1 硬體名稱 Freescale i.MX8QM MEK (DT) 呼叫追踪
    dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x64/0x80 dump_stack+0x1c/0x38
    __might_resched+0x1fc/0x240 __might_sleep+0x68/0xc0 __pm_runtime_resume+0x9c/0xe0 rpm_get_suppliers+0x68/0x1b0 __pm_runtime_set_status+0x298/0x560 cdns_resume+0xb0/0x1c0 cdns3_controller_resume.isra.0+0x1e0/0x250 cdns3_plat_resume+0x28/0x40 (CVE-2023-53287)

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

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

  - mtdmappxa2xx-flash修正重新對應錯誤時探查釋放「info」的記憶體洩漏以避免記憶體洩漏。
    [<miquel.raynal@bootlin.com>重寫提交記錄] (CVE-2022-50324)

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

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

  - nubus部分還原 proc_create_single_data() 轉換 至 proc_create_single_data() 的轉換引入了回歸問題讀取 /proc/bus/nubus 中的檔案導致分割錯誤# grep -r 。
    /proc/bus/nubus/e/ Super Data 中0x00000020 的資料讀取錯誤 (pc=0x1074c2) 錯誤 核心緩衝區 Oops
    00000000 模組連結至 PC [<001074c2>] PDE_DATA+0xc/0x16 SR2010 SP38284958 a201152370 d0
    00000001 d1: 01013000 d2: 01013000 d2: 01002790 d3: 00000000 d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40 處理程序 (pid: 45, task=142f8727) 框架格式=B s=04d5e 是 daddr=00000020 dobuf=01199e70 baddr=001074c8 dibuf=ffffffff ]ver=2b s=8c 是 [b s=2] Stack from 01199e48: 01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000 00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000 d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000 00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640 011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c 000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0 呼叫追踪 [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0 [<000d551a>] seq_read+0xc4/0x510 [<00018000>] fp_fcos+0x2/0x82 [<0002800d>] __sys_setreuid+0x115/0x1c6 [<00103640>] proc_reg_read+0x5/0b0 [<00018000>] fp_fcos+0x2/0x82 [<000b3344>] __vfs_read+0x2c/0x13c [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b8aa2>] sys_statx+0x60/0x7e [<000b34b6>] vfs_read +0x62/0x12a [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b39c2>] ksys_read+0x48/0xbe [<00018000>] fp_fcos+0x2/0x82 [<000b3a4e>] sys_read+0x16/0x1a [<00018000>] fp_fcos+0x2/0x82 [<00002b84>] syscall+0x8/0xc [<00018000>] fp_fcos +0x2/0x82 [<0000c016>] not_ext+0xa/0x18 Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8 Disabling lock debugging due to kernel taint Segmentation fault The proc_create_single_data() 轉換沒有作用因為 single_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) 不等同於原始程式碼。 (CVE-2023-53217)

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

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

  - 已解決 Linux 核心中的下列弱點：firmware: stratix10-svc: Fix a potential resource leak in svc_create_memory_pool() svc_create_memory_pool() is only called from stratix10_svc_drv_probe(). Most of resources in the probe are managed, but not this memremap() call. There is also no memunmap() call in the file. So switch to devm_memremap() to avoid a resource leak.
    (CVE-2023-53255)

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

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

  - androidbinder停止儲存 VMA 的指標不記錄 mmap_lock 之外的 VMA 指標以供日後使用。這是不安全的而且在設定期間可能釋放已記錄的 VMA 指標*之後*有一些失敗路徑。驅動程式沒有回呼可清除泛型 mm 程式碼中已儲存的指標。此外如果有任意數量的 VMA 作業結束釋放 VMA則 VMA 指標可能會過時因此儲存該 VMA 後會變得很脆弱。請改為變更 binder_alloc 結構以記錄 VMA 的起始位址並在需要時使用 vma_lookup() 取得 vma。新增 vma 指標更新時的 lockdep mmap_lock 檢查以確保鎖定已保留並依賴該鎖定來同步讀取器和寫入器 - 反正情況已經如此因此不需要 smp_wmb()/smp_rmb()。
    [akpm@linux-foundation.org修正 drivers/android/binder_alloc_selftest.c] (CVE-2022-50240)

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

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

  - 已解決 Linux 核心中的下列弱點：sctp: handle the error returned from sctp_auth_asoc_init_active_key When it returns an error from sctp_auth_asoc_init_active_key(), the active_key is actually not updated. The old sh_key will be freeed while it's still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot:
    sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 This patch is to fix it by not replacing the sh_key when it returns errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key(). For sctp_auth_set_active_key(), old active_key_id will be set back to asoc->active_key_id when the same thing happens. (CVE-2022-50243)

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

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

  - ubi確保 VID 標頭位移 + VID 標頭大小 <= alloc, size 確保 VID 標頭位移 + VID 標頭大小不會超過為避免平台 OOB 而配置的區域。BUGKASAN crc32_body lib/crc32.c:111 中的 slab 超出邊界 [內嵌] 錯誤 KASAN crc32_le_generic lib/crc32.c:179 中的 slab 超出邊界 [內嵌] 錯誤KASAN crc32_le_base+0x58c/0x626 lib/crc32.c:197 中的 slab 超出邊界透過工作 syz-executor136/1555 CPU 在 addr ffff88802bb36f00 讀取大小 4 CPU2 PID1555 通訊syz-executor136 污染GW 6.0.0-1868 #1 硬體名稱Red Hat KVM、BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 2014 年 4 月 1 日 呼叫追踪 <TASK> __dump_stack lib/dump_stack.c:88 [內嵌] dump_stack_lvl+0x85/0xad lib /dump_stack.c:106 print_address_description mm/kasan/report.c:317 [內嵌] print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433 kasan_report+0xa7/0x11b mm/kasan/report.c 495 crc32_body lib/crc32.c:111 [內嵌] crc32_le_generic lib/crc32.c:179 [內嵌] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c 1067 create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [內嵌] ubi_read_volume_table+0x67b/0 x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers /mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [內嵌] __do_sys_ioctl fs/ioctl.c:870 [內嵌] __se_sys_ioctl fs/ioctl.c:856 [內嵌] __x64_sys_ioctl+0x193/0x213 fs/ ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [內嵌] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 RIP 0033:0x7f96d5cf753d 程式碼RSP 002b:00007fffd72206f8 EFLAGS
    00000246 ORIG_RAX 0000000000000010 RAX ffffffffffffffda RBX 0000000000000000 RCX 00007f96d5cf753d RDX
    0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003 RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 R13:
    00007fffd72207e0 R140000000000000000 R150000000000000000 </TASK> 由工作 1555 分配
    kasan_save_stack+0x20/0x3d mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [內嵌] set_alloc_info mm/kasan/common.c:437 [內嵌]____kasan_kmalloc mm/kasan/common.c:516 [內嵌]
    __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525 kasan_kmalloc include/linux/kasan.h:234 [內嵌]
    __kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc include/linux/slab.h:605 [內嵌] ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [內嵌] create_vtbl+0xcc/0x9c4 drivers/mtd/ubi /vtbl.c:295 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [內嵌] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach。 c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [內嵌] __do_sys_ioctl fs/ioctl .c:870 [內嵌] __se_sys_ioctl fs/ioctl.c:856 [內嵌]
    __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [內嵌] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 該錯誤位址屬於 ffff88802bb36e00 處的物件其屬於大小 256 的快取 kmalloc-256 錯誤位址位於 256 位元組區域右側 0 位元組 [ffff88802bb36e00, ffff88802bb36f00) 錯誤位址屬於實體頁面page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2bb36 head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 flags0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw
    000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40 raw 0000000000000000 00000000001
    ---truncated--- (CVE-2023-53265)

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

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

  - io_uring/af_unix將已註冊的檔案 gc 延遲至 io_uring 版本我們不想將 io_uring 的已註冊檔案放在 unix_gc() 中而是希望由 io_uring 本身完成。此處的訣竅是考慮 io_uring 註冊檔案進行週期偵測但不會實際將其記錄下來。由於 io_uring 無法註冊其他環執行個體因此此操作會移除觸發 ->release 路徑的所有環檔案參照並使用 io_ring_ctx_free() 進行清理。 [axboe新增 kerneldoc 註解至 skb、折疊 skb 洩漏修正] (CVE-2022-50234)

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

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

  - atmatmtcp防止 atmtcp_recv_control() 中的任意寫入。 syzbot 報告了以下問題。 [0] 透過 connect() 或 close() 呼叫 atmtcp_v_open() 或 atmtcp_v_close() 時系統會呼叫 atmtcp_send_control() 以傳送核心內特殊訊息。訊息的 atmtcp_control.hdr.length 中有 ATMTCP_HDR_MAGIC。此外結構 atm_vcc 的指標設定為 atmtcp_control.vcc。值得注意的是 struct atmtcp_control 是 uAPI但有一個空間供一個核心內指標使用。 struct atmtcp_control { struct atmtcp_hdr hdr; /* 必須在前面
    */ ... atm_kptr_t vcc /* 兩個方向 */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; }
    __ATM_API_ALIGN atm_kptr_t特殊訊息是在從 atmtcp_c_send() 呼叫的 atmtcp_recv_control() 中處理。 atmtcp_c_send() 是 vcc->dev->ops->send()並從 2 個路徑呼叫1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg() 問題在於 sendmsg () 不會驗證訊息長度而且使用者空間可濫用 atmtcp_recv_control() 以 atmtcp_control 覆寫任何 kptr。讓我們新增一個 ->pre_send() 勾點以驗證來自 sendmsg() 的訊息。 [0]Oops一般保護錯誤可能是針對非正式位址 0xdffffc00200000ab0000 [#1] SMP KASAN PTI KASAN 可能是使用者記憶體存取範圍 [0x0000000100000558-0x000000010000055f] CPU0 UID0 PID 5865 Commsyz-executor331 未受污染的 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(完整) 硬體名稱: Google Google Compute Engine/Google Compute Engine、BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/ atm/atmtcp.c:93 [內嵌] RIP0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 代碼4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c ff ff:130018 EFLAGS00010203 RAX
    00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10:
     R11dffffc0000000000  : ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg +0x505/0x830 net/socket.c:2614
    ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [內嵌] __do_sys_sendmsg net/socket.c:2705 [內嵌] __se_sys_sendmsg net/socket.c:2703 [內嵌] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [內嵌] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP0033:0x7f8d7e96a4a9 程式碼28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 3 01 f 0 ff 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP
    002b:00007f8d7e923198 EFLAGS00000246 ORIG_RAX: 000000000000002e RAXffffffffffffffda RBX
    00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11:
    0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> 連結於 的模組 (CVE-2025-39828)

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

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

  - 已解決 Linux 核心中的下列弱點：clk: socfpga: Fix memory leak in socfpga_gate_init() Free @socfpga_clk and @ops on the error path to avoid memory leak issue.
    (CVE-2022-50264)

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

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

  - pstore/ram檢查 init 期間空白 przs 的開始。提交 30696378f68a (pstore/ram 不將空緩衝區視為有效)之後初始化會在看到 buffer_size 為零後假設 prz 為有效 (無論緩衝區開始位置為何)。此未經檢查的開始值表示它可能超出緩衝區邊界導致日後在寫入至下列項目時發生存取錯誤sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78
    __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 ... 為避免此情況請在初始化階段檢查 prz start 是否為 0。否則，下一個 prz 功能健全檢查案例將會發現它 (開始 > 大小)，並將緩衝區快速切換回合理的狀態。 [kees使用反向追踪和說明更新提交記錄] (CVE-2023-53331)

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

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

  - wifiiwl3945對 create_singlethread_workqueue 新增遺漏檢查。新增對 create_singlethread_workqueue 傳回值的檢查避免 NULL 指標解除參照。 (CVE-2023-53277)

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

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

  - io_uring/kbuf修正 this_len 計算中的正負號。當匯入和使用緩衝區時buf->len 會被視為未簽署。但是buf->len 會在認可時轉換為 signed int。如果緩衝區大到足以被解譯為負值這可能會導致未預期的行為。使 min_t 計算不帶正負號。 (CVE-2025-39822)

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

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

  - 已解決 Linux 核心中的下列弱點：driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event() The kfree() should be called when memory fails to be allocated for cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be a memory leak, so add kfree() to fix it. (CVE-2023-53267)

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

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

  - 已解決 Linux 核心中的下列弱點：HID: intel-thc-hid: intel-thc: Fix incorrect pointer arithmetic in I2C regs save Improper use of secondary pointer (&dev->i2c_subip_regs) caused kernel crash and out-of-bounds error: BUG: KASAN: slab-out-of-bounds in
    _regmap_bulk_read+0x449/0x510 Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107 CPU: 3 UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary) Workqueue: async async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x660 ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x26/0x200 kasan_report+0xe1/0x120 ? _regmap_bulk_read+0x449/0x510 ? _regmap_bulk_read+0x449/0x510
    __asan_report_store4_noabort+0x17/0x30 _regmap_bulk_read+0x449/0x510 ? __pfx__regmap_bulk_read+0x10/0x10 regmap_bulk_read+0x270/0x3d0 pio_complete+0x1ee/0x2c0 [intel_thc] ? __pfx_pio_complete+0x10/0x10 [intel_thc] ? __pfx_pio_wait+0x10/0x10 [intel_thc] ? regmap_update_bits_base+0x13b/0x1f0 thc_i2c_subip_pio_read+0x117/0x270 [intel_thc] thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc] ?
    __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc] [...] The buggy address belongs to the object at ffff888136005d00 which belongs to the cache kmalloc-rnd-12-192 of size 192 The buggy address is located 0 bytes to the right of allocated 192-byte region [ffff888136005d00, ffff888136005dc0) Replaced with direct array indexing (&dev->i2c_subip_regs[i]) to ensure safe memory access. (CVE-2025-39818)

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

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

  - 已解決 Linux 核心中的下列弱點：hwmon: (pmbus_core) Fix NULL pointer dereference Pass i2c_client to _pmbus_is_enabled to drop the assumption that a regulator device is passed in. This will fix the issue of a NULL pointer dereference when called from _pmbus_get_flags.
    (CVE-2023-53206)

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

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

  - drm/client修正 drm_client_modeset_probe 中的記憶體洩漏。將新模式設定為 modeset->mode 時應釋放先前的模式。This fixes the following kmemleak report: drm_mode_duplicate+0x45/0x220 [drm] drm_client_modeset_probe+0x944/0xf50 [drm] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper] drm_client_register+0x169/0x240 [drm] ast_pci_probe+0x142 /0x190 [ast] local_pci_probe+0xdc/0x180 work_for_cpu_fn+0x4e/0xa0 process_one_work+0x8b7/0x1540 worker_thread+0x70a/0xed0 kthread+0x29f/0x340 ret_from_fork+0x1f/0x30 (CVE-2023-53288)

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

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

  - 已解決 Linux 核心中的下列弱點：media: ov8865: Fix an error handling path in ov8865_probe() The commit in Fixes also introduced some new error handling which should goto the existing error handling path. Otherwise some resources leak. (CVE-2022-50254)

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

ID	名稱	嚴重性
265201	Linux Distros 未修補的弱點：CVE-2023-53166	medium
265200	Linux Distros 未修補的弱點：CVE-2022-50261	medium
265199	Linux Distros 未修補的弱點：CVE-2025-39819	medium
265198	Linux Distros 未修補的弱點：CVE-2025-39835	high
265197	Linux Distros 未修補的弱點：CVE-2023-53262	high
265196	Linux Distros 未修補的弱點：CVE-2023-53175	medium
265195	Linux Distros 未修補的弱點：CVE-2025-39810	high
265194	Linux Distros 未修補的弱點：CVE-2023-53292	medium
265193	Linux Distros 未修補的弱點：CVE-2023-53172	medium
265192	Linux Distros 未修補的弱點：CVE-2023-53295	medium
265191	Linux Distros 未修補的弱點：CVE-2023-53334	medium
265190	Linux Distros 未修補的弱點：CVE-2023-53238	high
265189	Linux Distros 未修補的弱點：CVE-2023-53280	medium
265188	Linux Distros 未修補的弱點：CVE-2022-50292	medium
265187	Linux Distros 未修補的弱點：CVE-2022-50291	medium
265186	Linux Distros 未修補的弱點：CVE-2025-10529	medium
265185	Linux Distros 未修補的弱點：CVE-2025-39834	medium
265184	Linux Distros 未修補的弱點：CVE-2023-53187	high
265182	Linux Distros 未修補的弱點：CVE-2025-59375	high
265181	Linux Distros 未修補的弱點：CVE-2023-53268	medium
265180	Linux Distros 未修補的弱點：CVE-2023-53282	high
265179	Linux Distros 未修補的弱點：CVE-2022-50277	medium
265178	Linux Distros 未修補的弱點：CVE-2023-53290	medium
265177	Linux Distros 未修補的弱點：CVE-2023-53263	high
265176	Linux Distros 未修補的弱點：CVE-2023-53177	medium
265175	Linux Distros 未修補的弱點：CVE-2023-53270	medium
265174	Linux Distros 未修補的弱點：CVE-2025-10536	medium
265173	Linux Distros 未修補的弱點：CVE-2023-53317	medium
265172	Linux Distros 未修補的弱點：CVE-2022-50330	medium
265171	Linux Distros 未修補的弱點：CVE-2023-53286	high
265170	Linux Distros 未修補的弱點：CVE-2022-50273	medium
265169	Linux Distros 未修補的弱點：CVE-2025-4953	high
265168	Linux Distros 未修補的弱點：CVE-2023-53287	medium
265167	Linux Distros 未修補的弱點：CVE-2022-50324	medium
265166	Linux Distros 未修補的弱點：CVE-2023-53217	high
265165	Linux Distros 未修補的弱點：CVE-2023-53255	medium
265164	Linux Distros 未修補的弱點：CVE-2022-50240	high
265163	Linux Distros 未修補的弱點：CVE-2022-50243	high
265162	Linux Distros 未修補的弱點：CVE-2023-53265	high
265161	Linux Distros 未修補的弱點：CVE-2022-50234	high
265160	Linux Distros 未修補的弱點：CVE-2025-39828	high
265159	Linux Distros 未修補的弱點：CVE-2022-50264	medium
265158	Linux Distros 未修補的弱點：CVE-2023-53331	high
265157	Linux Distros 未修補的弱點：CVE-2023-53277	medium
265156	Linux Distros 未修補弱點：CVE-2025-39822	medium
265155	Linux Distros 未修補的弱點：CVE-2023-53267	medium
265153	Linux Distros 未修補的弱點：CVE-2025-39818	high
265152	Linux Distros 未修補的弱點：CVE-2023-53206	medium
265151	Linux Distros 未修補的弱點：CVE-2023-53288	medium
265150	Linux Distros 未修補的弱點：CVE-2022-50254	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

high

high

medium

high

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

high

high

medium

high

medium

medium

high

medium

medium

medium

medium

medium

high

medium

high

medium

medium

high

medium

high

high

high

high

high

medium

high

medium

medium

medium

high

medium

medium

medium