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

  - scsi還原 scsicore如果分派失敗則不增加 scsi_device 的 iorequest_cntscsi_queue_rq() 中的 atomic_inc(&cmd->device->iorequest_cnt) 會造成核心錯誤因為 cmd->device 可能在從 scsi_dispatch_cmd() 返回後釋放。這會還原認可 cfee29ffb45b1c9798011b19d454637d1b0fe87d。 (CVE-2023-53609)

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

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

  - 已解決 Linux 核心中的下列弱點：coresight: cti: Fix hang in cti_disable_hw() cti_enable_hw() and cti_disable_hw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware. Since commit 3c6656337852 (Revert firmware: arm_scmi: Add clock management to the SCMI power domain), this causes a hang on Juno when running the Perf Coresight tests or running this command: perf record -e cs_etm//u -- ls This was also missed until the revert commit because pm_runtime_put() was called with the wrong device until commit 692c9a499b28 (coresight: cti: Correct the parameter for pm_runtime_put) With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent:
    20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected:
    0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88
    __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174 Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace. [ Fix build warnings ] (CVE-2022-50491)

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

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

  - 已解決 Linux 核心中的下列弱點：mm/damon/core: initialize damo_filter->list from damos_new_filter() damos_new_filter() is not initializing the list field of newly allocated filter object. However, DAMON sysfs interface and DAMON_RECLAIM are not initializing it after calling damos_new_filter(). As a result, accessing uninitialized memory is possible. Actually, adding multiple DAMOS filters via DAMON sysfs interface caused NULL pointer dereferencing. Initialize the field just after the allocation from damos_new_filter(). (CVE-2023-53555)

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

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

  - 已解決 Linux 核心中的下列弱點：wifi: mt76: mt76x0: fix oob access in mt76x0_phy_get_target_power After 'commit ba45841ca5eb (wifi: mt76: mt76x02: simplify struct mt76x02_rate_power)', mt76x02 relies on ht[0-7] rate_power data for vht mcs{0,7}, while it uses vth[0-1] rate_power for vht mcs {8,9}. Fix a possible out-of-bound access in mt76x0_phy_get_target_power routine.
    (CVE-2022-50508)

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

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

  - ext4新增 EXT4_IGET_BAD 旗標以防止未預期的錯誤 inode ext4_iget() 傳回錯誤的 inode 時有許多位置會變得不正常 (及損毀)。不過如果 iget 開機載入器 inode則 會允許傳回錯誤的 inode因為該 inode 可能未初始化。此機制可用來繞過某些檢查並造成不穩定。為了解決此問題我們新增了一個特殊的 iget 旗標 EXT4_IGET_BAD。只有使用此旗標我們才會從 ext4_iget() 傳回錯誤的 inode否則我們一律會在 inode 是錯誤的 inode 時傳回錯誤碼。(由 Jan Kara 建議) (CVE-2022-50485)

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

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

  - 已解決 Linux 核心中的下列弱點：irqchip: Fix refcount leak in platform_irqchip_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
    (CVE-2023-53610)

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

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

  - 已解決 Linux 核心中的下列弱點：net/mlx5e: Fix deadlock in tc route query code Cited commit causes ABBA deadlock[0] when peer flows are created while holding the devcom rw semaphore. Due to peer flows offload implementation the lock is taken much higher up the call chain and there is no obvious way to easily fix the deadlock. Instead, since tc route query code needs the peer eswitch structure only to perform a lookup in xarray and doesn't perform any sleeping operations with it, refactor the code for lockless execution in following ways: - RCUify the devcom 'data' pointer. When resetting the pointer synchronously wait for RCU grace period before returning. This is fine since devcom is currently only used for synchronization of pairing/unpairing of eswitches which is rare and already expensive as-is. - Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag has already been used in some unlocked contexts without proper annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn't an issue since all relevant code paths checked it again after obtaining the devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as best effort check to return NULL when devcom is being unpaired. Note that while RCU read lock doesn't prevent the unpaired flag from being changed concurrently it still guarantees that reader can continue to use 'data'. - Refactor mlx5e_tc_query_route_vport() function to use new mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock. [0]: [ 164.599612] ====================================================== [ 164.600142] WARNING:
    possible circular locking dependency detected [ 164.600667] 6.3.0-rc3+ #1 Not tainted [ 164.601021]
    ------------------------------------------------------ [ 164.601557] handler1/3456 is trying to acquire lock: [ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at:
    mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.603078] but task is already holding lock: [ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [164.604459] which lock already depends on the new lock. [ 164.605190] the existing dependency chain (in reverse order) is: [ 164.605848] -> #1 (&comp->sem){++++}-{3:3}: [ 164.606380] down_read+0x39/0x50 [164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core] [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core] [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core] [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core] [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core] [164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core] [ 164.610741] tc_setup_cb_add+0xd4/0x200 [164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower] [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower] [ 164.612116] tc_new_tfilter+0x3fc/0xd20 [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0 [164.612936] netlink_rcv_skb+0x54/0x100 [ 164.613339] netlink_unicast+0x190/0x250 [ 164.613746] netlink_sendmsg+0x245/0x4a0 [ 164.614150] sock_sendmsg+0x38/0x60 [ 164.614522] ____sys_sendmsg+0x1d0/0x1e0 [ 164.614934] ___sys_sendmsg+0x80/0xc0 [ 164.615320] __sys_sendmsg+0x51/0x90 [ 164.615701] do_syscall_64+0x3d/0x90 [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}: [ 164.617210] __lock_acquire+0x159e/0x26e0 [ 164.617638] lock_acquire+0xc2/0x2a0 [ 164.618018] __mutex_lock+0x92/0xcd0 [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.618943] post_process_attr+0x153/0x2d0 [ ---truncated--- (CVE-2023-53591)

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

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

  - 已解決 Linux 核心中的下列弱點：eth: alx: take rtnl_lock on resume Zbynek reports that alx trips an rtnl assertion on resume: RTNL: assertion failed at net/core/dev.c (2891) RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0 Call Trace: <TASK> __alx_open+0x230/0x570 [alx] alx_resume+0x54/0x80 [alx] ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x4a/0x150 device_resume+0x8b/0x190 async_resume+0x19/0x30 async_run_entry_fn+0x30/0x130 process_one_work+0x1e5/0x3b0 indeed the driver does not hold rtnl_lock during its internal close and re-open functions during suspend/resume. Note that this is not a huge bug as the driver implements its own locking, and does not implement changing the number of queues, but we need to silence the splat. (CVE-2022-50498)

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

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

  - dramddisplay修正記憶體洩漏此認可可修正 dc_construct_ctx() 函式中的記憶體洩漏。
    (CVE-2023-53605)

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

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

  - 已解決 Linux 核心中的下列弱點：net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume() Syzbot reported a bug as following:
    ===================================================== BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline]
    __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491
    __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630 qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048
    __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd It is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt) in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post(). But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot scenario. This triggers the uninit variable access bug. Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() to fix the bug. (CVE-2023-53578)

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

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

  - block、bfq修正「bfqq->bic」可能的 uaf 我們的測試報告在 5.10中有「bfqq->bic」的 uaf
    ================================================== ================ 錯誤KASANbfq_select_queue+0x378/0xa30 CPU 中的釋放後使用錯誤6 PID2318352 Commfsstress Kdump已載入但未受污染的 5.10.0-60.18 .0.50.h602.kasan.eulerosv2r11.x86_64 #1 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)、BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 2014 年 4 月 1 日 呼叫追踪
    bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0
    __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0
    __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90
    __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/ 0xc6 提交 3bc5e683c67d (bfq：在 cgroup 之間移動時分割共用佇列) 變更將處理程序移動到新 cgroup 時將會配置新的 bfqq 以供使用但是舊的 bfqq 和新的 bfqq 可以指向同一個 bic: 1) 初始狀態相同 cgroup 中有兩個具有 io 的處理程序。處理程序 1 處理程序 2 (BIC1) (BIC2) | | | | | | V | V | bfqq1 bfqq2 2) bfqq1 已合併至 bfqq2。處理程序 1 處理程序 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) 處理程序 1 結束後再從處理程序 2 發出新的 io(denoce IOA)。(BIC2) | | | V | bfqq2(coop) 4) 在 IOA 完成之前將處理程序 2 移至另一個 cgroup 並發出 io。處理程序 2 (BIC2) |\--------------\ | V bfqq2 bfqq3 BIC2 會指向 bfqq3而 bfqq2 和 bfqq3 都會指向 BIC2。如果所有要求都已完成處理程序 2 結束則 BIC2 會被釋放但不保證會在 BIC2 之前釋放 bfqq2。在 bfqq 與 bic 卸離時清除 bfqq->bic 以修正此問題。 (CVE-2022-50488)

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

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

  - 已解決 Linux 核心中的下列弱點：cpufreq: amd-pstate: fix global sysfs attribute type In commit 3666062b87ec (cpufreq: amd-pstate: move to use bus_get_dev_root()) the amd_pstate attributes where moved from a dedicated kobject to the cpu root kobject. While the dedicated kobject expects to contain kobj_attributes the root kobject needs device_attributes. As the changed arguments are not used by the callbacks it works most of the time. However CFI will detect this issue: [4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type:
    0x8651b1de) ... [ 4947.849409] Call Trace: [ 4947.849410] <TASK> [ 4947.849411] ? __warn+0xcf/0x1c0 [4947.849414] ? dev_attr_show+0x24/0x60 [ 4947.849415] ? report_cfi_failure+0x4e/0x60 [ 4947.849417] ? handle_cfi_failure+0x14c/0x1d0 [ 4947.849419] ? __cfi_show_status+0x10/0x10 [ 4947.849420] ? handle_bug+0x4f/0x90 [ 4947.849421] ? exc_invalid_op+0x1a/0x60 [ 4947.849422] ? asm_exc_invalid_op+0x1a/0x20 [ 4947.849424] ? __cfi_show_status+0x10/0x10 [ 4947.849425] ? dev_attr_show+0x24/0x60 [ 4947.849426] sysfs_kf_seq_show+0xa6/0x110 [ 4947.849433] seq_read_iter+0x16c/0x4b0 [ 4947.849436] vfs_read+0x272/0x2d0 [ 4947.849438] ksys_read+0x72/0xe0 [4947.849439] do_syscall_64+0x76/0xb0 [ 4947.849440] ? do_user_addr_fault+0x252/0x650 [ 4947.849442] ? exc_page_fault+0x7a/0x1b0 [ 4947.849443] entry_SYSCALL_64_after_hwframe+0x72/0xdc (CVE-2023-53550)

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

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

  - 10.1 之前的 OpenSSH 中的 ssh 允許 ssh:// URI 中使用「\0」字元從而可能在使用 ProxyCommand 時導致程式碼執行。 (CVE-2025-61985)

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

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

  - 10.1 之前的 OpenSSH 中的 ssh 允許控製字元在使用者名稱中源自於某些可能不受信任的來源進而可能在使用 ProxyCommand 時導致程式碼執行。不受信任的來源是命令行和設定檔的 %-sequence 擴充。(提供完整常值使用者名稱的設定檔不會被歸類為不受信任的來源。)(CVE-2025-61984)

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

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

  - jfs修正 diUnmount 中 JFS_IP(ipimap)->i_imap 的無效釋放 syzbot 在 diUnmount 中發現一個無效的釋放
    錯誤KASANslab_free mm/slub.c:3661 中雙重釋放 [內嵌] 錯誤KASAN 中雙重釋放
    __kmem_cache_free+0x71/0x110 mm/slub.c:3674 由工作 syz-executor131/3632 釋放位址 ffff88806f410000 的 CPU00 PID3632 通訊syz-executor131 未受污染的 6.1.0-rc7-syzkaller-00012-gca57f02295f1 硬體 #0 硬體名稱Google Google Compute Engine/Google Compute Engine、BIOS Google 10/26/2022 呼叫追踪 <TASK>
    __dump_stack lib/dump_stack.c:88 [內嵌] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c 395 kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460____kasan_slab_free+0xfb/0x120 kasan_slab_free include/linux/kasan.h:177 [內嵌] slab_free_hook mm/slub.c:1724 [內嵌] slab_free_freelist_hook+0x12e/0x1a0 mm /slub.c:1750 slab_free mm/slub.c:3661 [內嵌]
    __kmem_cache_free+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195 jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63 jfs_put_super+0x86/0x190 fs/jfs/super .c:194 generic_shutdown_super+0x130/0x310 fs/super.c:492 kill_block_super+0x79/0xd0 fs/super.c:1428 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 cleanup_mnt+0x494/0x520 fs/namespace.c 1186 task_work_run+0x243/0x300 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [內嵌] do_exit+0x664/0x2070 kernel/exit.c:820 do_group_exit+0x1fd/0x2b0 kernel/exit.c 950 __do_sys_exit_group kernel/exit.c:961 [內嵌] __se_sys_exit_group kernel/exit.c:959 [內嵌] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959 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 [...] JFS_IP(ipimap)->i_imap 在 diUnmount 中的釋放後未設定為 NULL。如果 jfs_remount() 會釋出 JFS_IP(ipimap)->i_imap但隨後在 diMount() 失敗。將會再次釋放 JFS_IP(ipimap)->i_imap。藉由在釋放後將 JFS_IP(ipimap)->i_imap 設為 NULL 來修正此問題。 (CVE-2023-53616)

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

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

  - 已解決 Linux 核心中的下列弱點：f2fs: fix to avoid use-after-free for cached IPU bio xfstest generic/019 reports a bug: kernel BUG at mm/filemap.c:1619! RIP:
    0010:folio_end_writeback+0x8a/0x90 Call Trace: end_page_writeback+0x1c/0x60 f2fs_write_end_io+0x199/0x420 bio_endio+0x104/0x180 submit_bio_noacct+0xa5/0x510 submit_bio+0x48/0x80 f2fs_submit_write_bio+0x35/0x300 f2fs_submit_merged_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_pages+0x30c/0x340 do_writepages+0xd8/0x1b0
    __writeback_single_inode+0x44/0x370 writeback_sb_inodes+0x233/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x2d0 wb_workfn+0x367/0x4a0 process_one_work+0x21d/0x430 worker_thread+0x4e/0x3c0 kthread+0x103/0x130 ret_from_fork+0x2c/0x50 The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write() in f2fs_write_single_data_page() tries to flush IPU bio in cache, however f2fs_submit_merged_ipu_write() missed to check validity of @bio parameter, result in submitting random cached bio which belong to other IO context, then it will cause use-after-free issue, fix it by adding additional validity check. (CVE-2023-53537)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/mediatek: mtk_drm_crtc: Add checks for devm_kcalloc As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference. (CVE-2023-53534)

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

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

  - 已解決 Linux 核心中的下列弱點：media: dvb-core: Fix double free in dvb_register_device() In function dvb_register_device() -> dvb_register_media_device() -> dvb_create_media_entity(), dvb->entity is allocated and initialized. If the initialization fails, it frees the dvb->entity, and return an error code. The caller takes the error code and handles the error by calling dvb_media_device_free(), which unregisters the entity and frees the field again if it is not NULL.
    As dvb->entity may not NULLed in dvb_create_media_entity() when the allocation of dvbdev->pad fails, a double free may occur. This may also cause an Use After free in media_device_unregister_entity(). Fix this by storing NULL to dvb->entity when it is freed. (CVE-2022-50499)

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

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

  - 剖析 DHAV 檔案的標頭時位移計算中發生整數反向溢位進而導致在配置緩衝區開始前讀取 的持續時間。如果我們載入的 DHAV 檔案大於 MAX_DURATION_BUFFER_SIZE 位元組 (0x100000) (例如0x101000 位元組)則大小為 0x101000。在 [1] 我們有 end_buffer_size = 0x100000而在 [2] 我們有 end_buffer_pos = 0x1000。然後迴圈會反向掃描尋找 dhav 標籤的緩衝區。當找到時我們會根據從緩衝區讀取的 32 位元位移來計算 end_pos。隨後會檢查 [3] end_pos 是否位於已復製到 end_buffer 中的檔案區段內但只會正確處理 end_pos 位於復製到 end_buffer 中的檔案區段之前或區段之後而不是end_pos 位於檔案內但在復製到 end_buffer 中的區段之前的情況。如果我們提供此類位移(end_pos - end_buffer_pos) 可反向溢位導致在 [4] 的後續存取發生在配置開始之前。建議升級至 8.0 版或更新版本。
    (CVE-2025-59729)

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

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

  - 已解決 Linux 核心中的下列弱點：crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked() When 9770b428b1a2 (crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown) moved the error messages dumping so that they don't need to be issued by the callers, it missed the case where __sev_firmware_shutdown() calls __sev_platform_shutdown_locked() with a NULL argument which leads to a NULL ptr deref on the shutdown path, during suspend to disk: #PF:
    supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops:
    0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022 RIP:
    0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp] That rIP is: 00000000000006fd <__sev_platform_shutdown_locked.cold>: 6fd: 8b 13 mov (%rbx),%edx 6ff: 48 8b 7d 00 mov 0x0(%rbp),%rdi 703:
    89 c1 mov %eax,%ecx Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e RSP: 0018:ffffc90005467d00 EFLAGS: 00010282 RAX: 00000000ffffff92 RBX: 0000000000000000 RCX:
    0000000000000000 ^^^^^^^^^^^^^^^^ and %rbx is nice and clean. Call Trace: <TASK>
    __sev_firmware_shutdown.isra.0 sev_dev_destroy psp_dev_destroy sp_destroy pci_device_shutdown device_shutdown kernel_power_off hibernate.cold state_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Pass in a pointer to the function-local error var in the caller. With that addressed, suspending the ccp shows the error properly at least: ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110 SEV-SNP:
    Leaking PFN range 0x146800-0x146a00 SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00] ... ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0 ACPI: PM: Preparing to enter system sleep state S5 kvm: exiting hardware virtualization reboot: Power down Btw, this driver is crying to be cleaned up to pass in a proper I/O struct which can be used to store information between the different functions, otherwise stuff like that will happen in the future again.
    (CVE-2025-39936)

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

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

  - 已解決 Linux 核心中的下列弱點：net: enetc: avoid buffer leaks on xdp_do_redirect() failure Before enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software BD in the RX ring between index orig_i and i can have one of 2 refcount values on its page. We are the owner of the current buffer that is being processed, so the refcount will be at least 1. If the current owner of the buffer at the diametrically opposed index in the RX ring (i.o.w, the other half of this page) has not yet called kfree(), this page's refcount could even be 2. enetc_page_reusable() in enetc_flip_rx_buff() tests for the page refcount against 1, and [ if it's 2 ] does not attempt to reuse it. But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call, the page refcount can have one of 3 values.
    It can also be 0, if there is no owner of the other page half, and xdp_do_redirect() for this buffer ran so far that it triggered a flush of the devmap/cpumap bulk queue, and the consumers of those bulk queues also freed the buffer, all by the time xdp_do_redirect() returns the execution back to enetc. This is the reason why enetc_flip_rx_buff() is called before xdp_do_redirect(), but there is a big flaw with that reasoning: enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the enetc_page_reusable() branch, and if xdp_do_redirect() returns an error, we call enetc_xdp_free(), which does not deal gracefully with that. In fact, what happens is quite special. The page refcounts start as 1.
    enetc_flip_rx_buff() figures they're reusable, transfers these rx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and bumps the refcount to 2. When xdp_do_redirect() later returns an error, we call the no-op enetc_xdp_free(), but we still haven't lost the reference to that page. A copy of it is still at rx_ring->next_to_alloc, but that has refcount 2 (and there are no concurrent owners of it in flight, to drop the refcount). What really kills the system is when we'll flip the rx_swbd->page the second time around. With an updated refcount of 2, the page will not be reusable and we'll really leak it.
    Then enetc_new_page() will have to allocate more pages, which will then eventually leak again on further errors from xdp_do_redirect(). The problem, summarized, is that we zeroize rx_swbd->page before we're completely done with it, and this makes it impossible for the error path to do something with it. Since the packet is potentially multi-buffer and therefore the rx_swbd->page is potentially an array, manual passing of the old pointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bit difficult. For the sake of going with a simple solution, we accept the possibility of racing with xdp_do_redirect(), and we move the flip procedure to execute only on the redirect success path. By racing, I mean that the page may be deemed as not reusable by enetc (having a refcount of 0), but there will be no leak in that case, either. Once we accept that, we have something better to do with buffers on XDP_REDIRECT failure. Since we haven't performed half-page flipping yet, we won't, either (and this way, we can avoid enetc_xdp_free() completely, which gives the entire page to the slab allocator). Instead, we'll call enetc_xdp_drop(), which will recycle this half of the buffer back to the RX ring. (CVE-2022-50483)

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

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

  - ASoC轉碼器sma1307修正 sma1307_setting_loaded() 中的記憶體損毀 sma1307->set.header_size 是標頭中的整數數 (共有 8 個)但我們分配的不是 8 個整數的空間而是配置 8 位元組。當我們在下一行複制資料時這會導致記憶體損毀
    memcpy(sma1307->set.header, data, sma1307->set.header_size * sizeof(int))此外由於我們會立即覆寫 ->set.header 中的記憶體因此不需要在配置器中將它歸零。改用 devm_kmalloc_array() 配置記憶體。 (CVE-2025-39935)

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

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

  - mtdlpddr2_nvm修正可能的 null-ptr-deref。如果 platform_get_resource() 傳回 NULL則會在叫用 resource_size(add_range) 時造成 null-ptr-deref。 (CVE-2022-50503)

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

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

  - 已解決 Linux 核心中的下列弱點：Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe rpi_firmware_get() take reference, we need to release it in error paths as well. Use devm_rpi_firmware_get() helper to handling the resources. Also remove the existing rpi_firmware_put().
    (CVE-2023-53533)

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

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

  - stagingks7010ks_wlan_set_encode_ext() 中有潛在的緩衝區溢位。exc->key_len 是來自使用者的 u16。超過 IW_ENCODING_TOKEN_MAX (64) 可導致記憶體損毀。
    (CVE-2023-53554)

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

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

  - 解碼使用 DWAA 或 DWAB 壓縮的 OpenEXR 檔案時隱含假設高度和寬度都可以被 8 整除。如果影像的高度或寬度不能被 8 整除複製會在 [0] 和 [ 1] 將繼續寫入直到下一個 8 的倍數。decode_block 中的緩衝區 td->uncompressed_data 是根據影像的確切高度和寬度進行配置因此復制迴圈中 8 的向上進位倍數可能會超過緩衝區在 [2] 開始的寫入區塊可損毀下列堆積記憶體。建議升級至 8.0 版或更新版本。 (CVE-2025-59732)

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

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

  - 解碼使用 DWAA 或 DWAB 壓縮的 OpenEXR 檔案時系統不會在使用 run-length-encoded 資料的指定原始長度來計算輸出資料時加以檢查。我們從 [0] 的輸入檔案中讀取 rle_raw_size解壓縮並解碼至 [1] 大小為 rle_raw_size 的緩衝區 td->rle_raw_data然後在 [2]我們將存取此緩衝區中最多 (td-> xsize - 1) * (td->ysize - 1) + rle_raw_size / 2其可能超過 rle_raw_size。建議升級至 8.0 版或更新版本。
    (CVE-2025-59731)

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

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

  - 已解決 Linux 核心中的下列弱點：usb: gadget: u_serial: Add null pointer check in gserial_resume Consider a case where gserial_disconnect has already cleared gser->ioport.
    And if a wakeup interrupt triggers afterwards, gserial_resume gets called, which will lead to accessing of gser->ioport and thus causing null pointer dereference.Add a null pointer check to prevent this. Added a static spinlock to prevent gser->ioport from becoming null after the newly added check. (CVE-2023-53551)

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

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

  - nilfs2修正 nilfs_segctor_thread() 中 nilfs_sc_info 結構的潛在 UAF。nilfs_segctor_thread() 的最終確定可能與終止該執行緒的 nilfs_segctor_kill_thread() 爭用可能在 KASAN 偵測到時造成釋放後使用錯誤。在 nilfs_segctor_thread() 結尾時它會將 NULL 指派給結構 nilfs_sc_info 的 sc_task 成員以指示執行緒已完成然後在結構 nilfs_sc_info 上使用 waitqueue sc_wait_task將此通知 nilfs_segctor_kill_thread()。不過在這里當 NULL 指派給 sc_task 之後nilfs_segctor_kill_thread() 可能會立即偵測到它並返回繼續解除配置進而在執行緒發出通知之前釋放 nilfs_sc_info 結構。這會修正此問題方法是使用結構 nilfs_sc_info 的 spinlock sc_state_lock 保護對 sc_task 的 NULL 指派及其通知。由於 nilfs_segctor_kill_thread() 會執行最後檢查以查看 sc_task 是否為鎖定 sc_state_lock 的 NULL因此這可消除爭用。
    (CVE-2023-53608)

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

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

  - 解碼使用 DWAA 或 DWAB 壓縮的 OpenEXR 檔案時會隱含假設所有影像通道都具有相同的像素類型 (和大小)且如果有四個通道則前四個為 B、G、R 和 A通道剖析程式碼可在 decode_header 中找到。緩衝區 td->uncompressed_data 在 decode_block 中是根據 xsize、ysize 和計算出的 current_channel_offset 進行配置。dwa_uncompress 函式接著在 [5] 假設如果有 4 個通道分別是 B、G、R 和 A並在 [6] 和 [7] 的計算中假設所有通道都是相同類型這符合主要色彩通道的類型。如果我們將主要色彩通道設定為 4 位元組類型並新增 2 位元組 EXR_HALF 類型的重複或未知通道則 [7] 的新增項目會將指標增加 4 位元組 * xsize * nb_channels這將超過配置的緩衝區。建議升級至 8.0 版或更新版本。 (CVE-2025-59733)

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

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

  - Litestar 是一種非同步伺服器閘道介面 (ASGI) 架構。在 2.17.0版中可透過操控 X-Forwarded-For 標頭完全繞過速率限制。這會使 IP 型速率限制對有心的攻擊者無效。Litestar 的 RateLimitMiddleware 使用 `cache_key_from_request()` 來產生速率限制的快取金鑰。當存在 X-Forwarded-For 標頭時中介軟體會無條件地信任它並使用其值作為用戶端識別碼的一部分。由於用戶端可設定任意 X-Forwarded-For 值因此每個不同的偽造 IP 都會建立獨立的速率限制值區。攻擊者可輪替使用不同的標頭值以避免達到任何單一值區的限制。這會影響以預設設定使用 RateLimitMiddleware 的任何 Litestar 應用程式其中可能包括大多數實作速率限制的應用程式。版本 2.18.0 包含一個弱點的修補程式。
    (CVE-2025-59152)

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

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

  - 已解決 Linux 核心中的下列弱點：perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start() Since commit 096b52fd2bb4 (perf: RISC-V: throttle perf events) the perf_sample_event_took() function was added to report time spent in overflow interrupts. If the interrupt takes too long, the perf framework will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.
    When hwc->interrupts is larger than max_samples_per_tick, the hwc->interrupts will be set to MAX_INTERRUPTS, and events will be throttled within the __perf_event_account_interrupt() function.
    However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler() function to avoid throttling. When the perf framework unthrottled the event in the timer interrupt handler, it triggers riscv_pmu_start() function and causes a WARN_ON_ONCE() warning, as shown below: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e Modules linked in: CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1 Hardware name: SiFive (DT) epc : riscv_pmu_start+0x7c/0x8e ra :
    riscv_pmu_start+0x28/0x8e epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0 gp :
    ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0 t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720 s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000 a2 :
    0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000 a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030 s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00 s5 :
    ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000 s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340 s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796 t5 :
    0000000700000000 t6 : ffffaf8005269870 status: 0000000200000100 badaddr: 0000000000000000 cause:
    0000000000000003 [<ffffffff80aef864>] riscv_pmu_start+0x7c/0x8e [<ffffffff80185b56>] perf_adjust_freq_unthr_context+0x15e/0x174 [<ffffffff80188642>] perf_event_task_tick+0x88/0x9c [<ffffffff800626a8>] scheduler_tick+0xfe/0x27c [<ffffffff800b5640>] update_process_times+0x9a/0xba [<ffffffff800c5bd4>] tick_sched_handle+0x32/0x66 [<ffffffff800c5e0c>] tick_sched_timer+0x64/0xb0 [<ffffffff800b5e50>] __hrtimer_run_queues+0x156/0x2f4 [<ffffffff800b6bdc>] hrtimer_interrupt+0xe2/0x1fe [<ffffffff80acc9e8>] riscv_timer_interrupt+0x38/0x42 [<ffffffff80090a16>] handle_percpu_devid_irq+0x90/0x1d2 [<ffffffff8008a9f4>] generic_handle_domain_irq+0x28/0x36 After referring other PMU drivers like Arm, Loongarch, Csky, and Mips, they don't call *_pmu_stop() to update with PERF_HES_STOPPED flag after perf_event_overflow() function nor do they add PERF_HES_STOPPED flag checking in *_pmu_start() which don't cause this warning. Thus, it's recommended to remove this unnecessary check in riscv_pmu_start() function to prevent this warning. (CVE-2023-53583)

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

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

  - python-socketio 是 Socket.IO 即時用戶端和伺服器的 Python 實作。在 5.14.0 之前的 python-socketio 版本中存在一個遠端程式碼執行弱點，允許攻擊者在多伺服器部署中透過惡意的 pickle 還原序列化執行任意 Python 程式碼，前提是攻擊者已經獲得伺服器之間用於內部通訊的訊息佇列存取權。當 Socket.IO 伺服器設為使用訊息佇列後端 (如 Redis) 進行伺服器間通訊時，在伺服器之間傳送的訊息會使用 Python 模組「pickle」進行編碼。當伺服器透過訊息佇列收到其中一個訊息時，會假設該訊息是受信任的，並立即將其還原序列化。此弱點是因為使用 Python 的「pickle.loads()」函式將訊息還原序列化所致。先前取得訊息佇列存取權的攻擊者可透過 Python 的「__reduce__」方法，將特製的 pickle 承載傳送給 python-socketio 伺服器，其可在還原序列化期間執行任意程式碼。此弱點只會影響訊息佇列受到入侵的部署。此攻擊可能導致攻擊者在 Socket.IO 伺服器處理程序的上下文中以其權限執行任意程式碼。不使用訊息佇列的單一伺服器系統，以及具有安全訊息佇列的多伺服器系統不會受到影響。除了確保在部署訊息佇列時遵循標準安全性做法，python-socketio 套件的使用者也可以升級至 5.14.0 版或更新版本，這些版本已移除「pickle」模組，並改用更安全的 JSON 編碼作為伺服器間訊息傳遞方式。(CVE-2025-61765)

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

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

  - xen/gntdev容納 VMA 分割在此認可之前gntdev 驅動程式程式碼無法正確處理下列具有並行虛擬化 (PV) Xen 網域的狀況* 使用者處理程序會設定由兩個授權對應 (即兩個頁面由另一個 Xen 網域共用)。 * 使用者處理程序 munmap()s 其中一個頁面。 * 使用者處理程序 munmap()s 剩餘頁面。 * 使用者處理程序存在。在上述狀況中使用者處理程序會使核心在 dmesg 中針對第一個 munmap() 記錄下列訊息而第二個 munmap() 呼叫則會產生類似的記錄訊息錯誤: 處理程序 doublemap.test 中發生錯誤的頁面對應pte:... pmd:... page:0000000057c97bff refcount:1 mapcount:-1 \ mapping:0000000000000000 索引:0x0 pfn:... ... 頁面轉儲存因為錯誤 pte ... file:gntdev error:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0 ... 呼叫追踪 <TASK> dump_stack_lvl+0x46/0x5e print_bad_pte.cold+0x66/0xb6 unmap_page_range+0x7e5/0xdc0 unmap_vmas+0x78/0xf0 unmap_region+0xa8/0x110
    __do_munmap+0x1ea/0x4e0 __vm_munmap+0x75/0x120 __x64_sys_munmap+0x28/0x40 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb ... 針對每個 munmap() 呼叫Xen Hypervisor (若是以 CONFIG_DEBUG 構建) 會列印下列內容並在受影響的 Xen PV 網域中觸發一般保護錯誤(XEN) d0v... 嘗試以隱含的方式取消對應 d0 的授權 PTE ... (XEN) d0v... 嘗試以隱含的方式取消對應 d0 的授權 PTE ... 撰寫本文時gntdev_grant_map 結構的 vma 欄位 (以下稱為 map->vma) 主要用於檢查對應的開始和結束位址。但是如果使用分割 VMA這些可能會變更且可能有多個 VMA 與 gntdev 對應相關聯。因此移除對 map->vma 的使用並依據 map->pages_vm_start 取得原始起始位址並依據 (map->count << PAGE_SHIFT) 取得原始對應大小。讓 invalidate() 和 find_special_page() 勾點使用這些項目。此外假設可能有多個 VMA 與 gntdev 對應關聯請將 mmu_interval_notifier_remove(&map->notifier) 呼叫移至 gntdev_put_map 的結尾以便只會在關閉最後一個剩餘 VMA 後移除 MMU 通知程式。最後使用不可部分完成以防止意外 gntdev 對應重複使用而不使用 map->live_grants 不可部分完成計數器及/或 map->vma 指標 (後者現已移除)。這可防止使用者空間在與之前設定的 gntdev 對應相同的位址範圍上對 gntdev 對應執行 mmap() (使用 MAP_FIXED)。此狀況可以概括為下列在此認可之前有效的呼叫追踪mmap gntdev_mmap mmap (使用 MAP_FIXED 在相同位址範圍上重複 mmap) gntdev_invalidate unmap_grant_pages (sets ' being_removed' 項目設為 true) gnttab_unmap_refs_async unmap_single_vma gntdev_mmap (maps重新建立共用頁面) munmap gntdev_invalidate unmap_grant_pages (無 op因為 ' being_removed' 項目為 true) unmap_single_vma (針對 PV 網域如果 Xen 構建了 Xen 網域則 Xen 會報告受影響網域中 會取消對應授予的頁面並觸發一般保護錯誤with CONFIG_DEBUG) 最後一種情況的修正可能值得自己進行提交但我們選擇了單一提交因為移除 gntdev_grant_map 結構的 vma 欄位需要保護 gntdev_mmap() 的項目而且其上的 live_grants 不可部分完成計數器以防止先前存在的對應上執行 mmap()。
    (CVE-2022-50471)

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

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

  - iavf修正 free_netdev 中的釋放後使用。我們會對所有已配置的 q_vectors[]進行 netif_napi_add()但可能會對其中部分進行 netif_napi_del()然後 kfree q_vector並將無效的指標留在 dev->napi_list。Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf=0000:41:00.0 vf0_dbsf=0000:41:02.0 g_pids=() function do_set_numvf() { echo 2 >/sys/bus/ pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z $nic ] && { sleep $((RANDOM%3)) ;傳回 1 } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combine 1 ethtool -L $nic combine 4 sleep $((RANDOM%3)) } function on_exit() { ${g_pids[@]} 中 pid 的本機 pid do kill -0 $pid &>/dev/null && kill $pid &>/dev/null done g_pids=() } 設陷 on_exit;
    時結束 EXIT do do_set_numvf ; done & g_pids+=($!) while do do_set_channel完成 & g_pids+=($!) wait 結果[ 4093.900222] =================================== =============================== [4093.900230] 錯誤KASANfree_netdev+0x308/0x390 中發生釋放後使用[ 4093.900232] 工作 repro.sh/6699 在 addr ffff88b4dc145640 讀取大小 8 [ 4093.900233] [ 4093.900236] CPU10 PID 6699 Commrepro.sh Kdump已載入 污染GO ------- -- -t - 4.18.0 #1 [ 4093.900238] 硬體名稱Power leader PR2008AL/H12DSi-N6、BIOS 2.0 2021 年 4 月 9 日 [ 4093.900239] 呼叫追踪 [ 4093.900244] dump_stack+0x71/0xab [4093.900249] print_address_description +0x6b/0x290 [ 4093.900251] ? free_netdev+0x308/0x390 [ 4093.900252] kasan_report+0x14a/0x2b0 [ 4093.900254] free_netdev+0x308/0x390 [ 4093.900261] iavf_remove+0x825/0xd20 [iavf] [ 4093.900265] pci_device_remove+0xa8/0x1f0 [ 4093.900268] device_release_driver_internal+ 0x1c6/0x460 [ 4093.900271] pci_stop_bus_device+0x101/0x150 [ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20 [ 4093.900275] pci_iov_remove_virtfn+0x187/0x420 [ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10 [ 4093.900278] pci_get_subsys+0x90/0x90 [ 4093.900280] sriov_disable+0xed/0x3e0 [ 4093.900282] ? bus_find_device+0x12d/0x1a0 [ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e] [ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e] [ 4093.900299] ? pci_get_device+0x7c/0x90 [ 4093.900300] ? pci_get_subsys+0x90/0x90 [ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210 [ 4093.900309] __mutex_lock_slowpath+0x10/0x10 [ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e] [ 4093.900318] sriov_numvfs_store+0x214/0x290 [ 4093.900320] ? sriov_totalvfs_show+0x30/0x30 [ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10 [ 4093.900323] ?
    __check_object_size+0x15a/0x350 [ 4093.900326] kernfs_fop_write+0x280/0x3f0 [ 4093.900329] vfs_write+0x145/0x440 [ 4093.900330] ksys_write+0xab/0x160 [ 4093.900332] ? __ia32_sys_read+0xb0/0xb0 [4093.900334] ? fput_many+0x1a/0x120 [ 4093.900335] ? filp_close+0xf0/0x130 [ 4093.900338] do_syscall_64+0xa0/0x370 [ 4093.900339] ? page_fault+0x8/0x30 [ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 4093.900357] RIP 0033:0x7f16ad4d22c0 [ 4093.900359] 代碼73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24 [ 4093.900360] RSP
    002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0 [ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001 [ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700 [4093.9003 ---truncated--- (CVE-2023-53556)

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

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

  - macintosh修正 macio_add_one_device() 在認可 1fa5ae857bb1 (驅動程式核心擺脫結構裝置的 bus_id 字串陣列)動態配置裝置名稱時可能發生的記憶體洩漏。當 of_device_register() 失敗時需要將其釋放。呼叫 put_device() 以放棄在 device_initialize() 中取得的參照如此當 refcount 達到 0 時可在 kobject_cleanup() 中釋放。macio 裝置會在 macio_release_dev() 中釋放因此可移除 kfree()。 (CVE-2022-50474)

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

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

  - PyVista 透過 Visualization Toolkit (VTK) 的介面提供 3D 繪圖和網格分析。
     0.46.3 版 PyVista Project 容易因相依性混淆而導致遠端程式碼執行。有兩條程式碼使用--extra-index-url`  `。但是當使用 `--extra-index-url` 時pip 一律先檢查 PyPI 索引再檢查外部索引。程式碼中所列的一個套件未以 PyPI 發布。如果攻擊者在 PyPI 中發布更高版本的套件則可能會從攻擊者控制的套件中提取惡意程式碼進而導致遠端程式碼執行和供應鏈攻擊。截至本文發佈時尚未提供修補版本。 (CVE-2025-61774)

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

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

  - mtdrawnandbrcmnand修正 oob 寫入中潛在的超出邊界存取。oob 緩衝區長度不是以字的倍數表示時oob 寫入函式會在最後重複時對 oob 來源緩衝區執行超出邊界讀取。藉由一律檢查 oob 緩衝區讀取的長度限制並在到達 oob 暫存器的緩衝區結尾時以 0xff 填入來修正該問題。 (CVE-2023-53541)

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

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

  - ext2在掛載期間檢查區塊大小有效性 檢查儲存在超級區塊中的區塊大小記錄是否具有合理的值。否則運算區塊大小的移位可能溢位而導致未定義的行為。
    (CVE-2023-53569)

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

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

  - ARM: dts: exynos使用 Exynos5420 相容於 MIPI 視訊 phy。不知為何在 2016 年新增 Exynos5420 MIPI phy 支援的驅動程式未在 Exynos5420 上使用這會造成核心錯誤。為其新增適當的相容項目。 (CVE-2023-53542)

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

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

  - 已解決 Linux 核心中的下列弱點：memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe() The break of for_each_available_child_of_node() needs a corresponding of_node_put() when the reference 'child' is not used anymore. Here we do not need to call of_node_put() in fail path as '!match' means no break. While the of_platform_device_create() will created a new reference by 'child' but it has considered the refcounting. (CVE-2022-50480)

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

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

  - mediacoda新增 dcoda_iram_alloc 的檢查由於 coda_iram_alloc 可能傳回 NULL 指標因此最好檢查傳回值以避免 NULL 指標解除參照 (與其他項目相同)。
    (CVE-2022-50501)

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

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

  - nilfs2修正 nilfs_sb2_bad_offset() 中的移位超出邊界/溢位問題系列修補程式 nilfs2修正掛載時的 UBSAN 移位超出邊界警告。第一個修補程式可修正 syzbot 報告的一個錯誤第二個則可修正其餘同類的錯誤。雖然是由相同的超級區塊資料異常所觸發但由於問題的詳細資訊和修正方法不同因此我還是將其分為上述兩個異常情況。兩者都是消除掛載時 shift-out-of-bounds 問題所必需的。此修補程式 (共 2 個)
    如果寫入磁碟上超級區塊的區塊大小指數資訊損毀則 nilfs_sb2_bad_offset 協助程式函式會觸發 shift-out-of-bounds 警告其後接著會發生核心錯誤 (若已設定 panic_on_warn)shift 指數 38983 對 64- 而言太大位元類型 'unsigned long long' 呼叫追踪 <TASK>
    __dump_stack lib/dump_stack.c:88 [內嵌] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [內嵌] __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322 nilfs_sb2_bad_offset fs/lfs2 /the_nilfs.c:449 [內嵌] nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523 init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577 nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c 1047 nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317 ... 此外由於 nilfs_sb2_bad_offset() 執行乘法時未考慮上限因此若磁碟配置參數不正常則計算可能溢位。這可修正這些問題方法為插入這些參數的初步功能健全檢查並將比較從涉及乘法和左位移位的比較轉換為使用除法和右位移的比較。 (CVE-2022-50478)

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

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

  - 為 SANM 檔案 (ANIM v0 變體) 解碼框架時解碼的資料可能大於為其配置的緩衝區。使用 codec 48 編碼的框架可以指定其解析度 (寬 x 高)。系統會根據解析度配置適當大小的緩衝區。此轉碼器可使用執行長度編碼演算法對框架內容進行編碼。不會檢查解碼的框架是否符合配置的緩衝區進而導致堆積緩衝區溢位。 process_frame_obj 會根據框架解析初始化緩衝區 建議升級至 8.0 版或更新版本。 (CVE-2025-59730)

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

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

  - 在 SANM 解碼中可能會造成使用 subversion <2 的特製動畫解碼時發生釋放後使用寫入。當存在 STOR 區塊時後續的 FOBJ 區塊將會儲存在 ctx->stored_frame 中。
    儲存的框架稍後可由 FTCH 區塊參照。針對使用 subversion < 2 的檔案未解碼的框架會被儲存並在剖析 FTCH 區塊時再次解碼。但是在 process_frame_obj 中如果框架的大小無效則會提早傳回值為 0。這會造成 decode_frame 中的程式碼仍將原始框架緩衝區儲存到 ctx->stored_frame 中。將 ctx->has_dimensions 設定為 false。FTCH 類型的後續區塊會呼叫 process_ftch 並再次解碼該框架 obj進而新增到 top/left 值並再次呼叫 process_frame_obj。假設我們之前從未設定過 ctx->have_dimensions因此這一次我們會呼叫 init_buffers 來設定尺寸其可重新配置 ctx->stored_frame 中的緩衝區進而釋放先前的緩衝區。不過GetByteContext 物件 gb 仍保留舊緩衝區的參照。最後當程式碼嘗試解碼框架時接受 GetByteContext 作為參數的轉碼器將在使用 gb 時觸發釋放後使用讀取。GetByteContext 只用於讀取位元組因此最多可讀取無效資料。在釋放物件與存取物件之間沒有堆積配置。不過在傳回 process_ftch 時程式碼會在stored_frame 中還原 top/left 的原始值並在位移 6 寫入 4 個位元組至已釋放資料進而可能損毀配置器的詮釋資料。僅透過探查檔案是否具有 sanm 格式即可觸發此問題。建議升級至 8.0 版或更新版本。 (CVE-2025-59734)

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

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

  - DokuWiki 2025-05-14a 'Librarian' 中的跨網站指令碼弱點[56.1] 允許遠端攻擊者透過 q 參數執行任意程式碼 (CVE-2025-61224)

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

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

  - 已解決 Linux 核心中的下列弱點：clk: rs9: Fix suspend/resume Disabling the cache in commit 2ff4ba9e3702 (clk: rs9: Fix I2C accessors) without removing cache synchronization in resume path results in a kernel panic as map->cache_ops is unset, due to REGCACHE_NONE. Enable flat cache again to support resume again. num_reg_defaults_raw is necessary to read the cache defaults from hardware.
    Some registers are strapped in hardware and cannot be provided in software. (CVE-2023-53573)

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

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

  - 已解決 Linux 核心中的下列弱點：gpio: sifive: Fix refcount leak in sifive_gpio_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
    (CVE-2023-53592)

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

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

  - Bucket 是 MediaWiki 延伸模組用來儲存和擷取文章上的結構化資料。在 1.0.0版之前如果使用者查詢使用 `!=` 比較器的值區可能會發生無限遞回。這會導致超出 PHP 的呼叫堆疊限制和/或增加記憶體消耗進而可能導致拒絕服務。1.0.0 版包含針對該問題的修補程式。(CVE-2025-61766)

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

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

  - 在 validator.js 之前的版本 13.15.15中存在一個 URL 驗證繞過弱點。isURL() 函式使用「://」做為分隔符號剖析通訊協定而瀏覽器使用「:」做為分隔符號。攻擊者可利用此剖析差異透過特製 URL 來繞過通訊協定和網域驗證這會導致 XSS 和開放重新導向攻擊。 (CVE-2025-56200)

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

ID	名稱	嚴重性
269345	Linux Distros 未修補的弱點：CVE-2023-53609	medium
269344	Linux Distros 未修補的弱點：CVE-2022-50491	medium
269343	Linux Distros 未修補的弱點：CVE-2023-53555	medium
269342	Linux Distros 未修補的弱點：CVE-2022-50508	high
269341	Linux Distros 未修補的弱點：CVE-2022-50485	medium
269340	Linux Distros 未修補的弱點：CVE-2023-53610	high
269339	Linux Distros 未修補的弱點：CVE-2023-53591	high
269338	Linux Distros 未修補的弱點：CVE-2022-50498	medium
269337	Linux Distros 未修補的弱點：CVE-2023-53605	high
269336	Linux Distros 未修補的弱點：CVE-2023-53578	high
269335	Linux Distros 未修補的弱點：CVE-2022-50488	medium
269334	Linux Distros 未修補的弱點：CVE-2023-53550	medium
269333	Linux Distros 未修補的弱點：CVE-2025-61985	low
269332	Linux Distros 未修補的弱點：CVE-2025-61984	low
269331	Linux Distros 未修補的弱點：CVE-2023-53616	high
269330	Linux Distros 未修補的弱點：CVE-2023-53537	high
269329	Linux Distros 未修補的弱點：CVE-2023-53534	medium
269328	Linux Distros 未修補的弱點：CVE-2022-50499	medium
269327	Linux Distros 未修補的弱點：CVE-2025-59729	medium
269326	Linux Distros 未修補的弱點：CVE-2025-39936	medium
269325	Linux Distros 未修補的弱點：CVE-2022-50483	medium
269324	Linux Distros 未修補的弱點：CVE-2025-39935	high
269323	Linux Distros 未修補的弱點：CVE-2022-50503	medium
269322	Linux Distros 未修補的弱點：CVE-2023-53533	medium
269321	Linux Distros 未修補的弱點：CVE-2023-53554	high
269320	Linux Distros 未修補的弱點：CVE-2025-59732	high
269319	Linux Distros 未修補的弱點：CVE-2025-59731	medium
269318	Linux Distros 未修補的弱點：CVE-2023-53551	medium
269317	Linux Distros 未修補的弱點：CVE-2023-53608	medium
269316	Linux Distros 未修補的弱點：CVE-2025-59733	high
269315	Linux Distros 未修補的弱點：CVE-2025-59152	high
269314	Linux Distros 未修補的弱點：CVE-2023-53583	medium
269313	Linux Distros 未修補的弱點：CVE-2025-61765	medium
269312	Linux Distros 未修補的弱點：CVE-2022-50471	high
269311	Linux Distros 未修補的弱點：CVE-2023-53556	high
269310	Linux Distros 未修補的弱點：CVE-2022-50474	medium
269309	Linux Distros 未修補的弱點：CVE-2025-61774	critical
269308	Linux Distros 未修補的弱點：CVE-2023-53541	high
269307	Linux Distros 未修補的弱點：CVE-2023-53569	high
269306	Linux Distros 未修補的弱點：CVE-2023-53542	medium
269305	Linux Distros 未修補的弱點：CVE-2022-50480	medium
269304	Linux Distros 未修補的弱點：CVE-2022-50501	medium
269303	Linux Distros 未修補的弱點：CVE-2022-50478	high
269302	Linux Distros 未修補的弱點：CVE-2025-59730	medium
269301	Linux Distros 未修補的弱點：CVE-2025-59734	high
269300	Linux Distros 未修補的弱點：CVE-2025-61224	medium
269299	Linux Distros 未修補的弱點：CVE-2023-53573	medium
269298	Linux Distros 未修補的弱點：CVE-2023-53592	high
269297	Linux Distros 未修補的弱點：CVE-2025-61766	medium
269296	Linux Distros 未修補的弱點：CVE-2025-56200	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

high

medium

high

high

medium

high

high

medium

medium

low

low

high

high

medium

medium

medium

medium

medium

high

medium

medium

high

high

medium

medium

medium

high

high

medium

medium

high

high

medium

critical

high

high

medium

medium

medium

high

medium

high

medium

medium

high

medium

medium