Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：fuse: Block access to folio overlimit syz reported a slab-out-of-bounds Write in fuse_dev_do_write. When the number of bytes to be retrieved is truncated to the upper limit by fc->max_pages and there is an offset, the oob is triggered. Add a loop termination condition to prevent overruns. (CVE-2025-39888)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - bpf告知 memcg 在 bpf_timer_init() 中使用 allow_spinning=false 路径 目前从 __bpf_async_init() 调用 bpf_map_kmalloc_node() 可造成各种锁定问题请参阅已针对 样式进行编辑的下列堆栈跟踪为一个示例... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) 双重获取相同的 [10.011575] kick_pool rq_lock从而导致 hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg 核算引发 [10.011597] obj_cgroup_charge_pages MEMCG_MAX 事件 [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603]
    __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF 调用 bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] bpf__sched_ext_ops_runnable [ [] ] 运行[10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) 获取 rq_lock ...
    通过修改 ./tools/sched_ext/scx_flatcg.bpf.c 以在 ops.runnable() 期间调用 bpf_timer_init()并且 hack memcg 核算代码做 bpf_timer_init()在 bpf-next (b338cf849ec8) 上重现上述问题。调用更有可能引发 MEMCG_MAX 事件。我们也遇到其他类似变体内部变体和 bpf-next 变体包括双重获取 cgroup_file_kn_lock、同一个 work_pool::lock 等。按照 Shakeel 的建议通过在 中使用 __GFP_HIGH 而非 GFP_ATOMIC 修复此问题
    __bpf_async_init()因此例如 try_charge_memcg() 引发 MEMCG_MAX 事件我们会调用
    __memcg_memory_event() 与 @allow_spinning=false 并避免在该处调用 cgroup_file_notify()。取决于 mm 修补程序 memcg如果不允许旋转则跳过 cgroup_file_notify
    https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/ v0 方法 s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 方法
    https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/ (CVE-2025-39886)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - hsr为 hsr_get_port_ndev 保持 rcu 和 dev 锁定其需要保持 rcu 锁定。 hsr_get_port_ndev 调用 hsr_for_each_port。另一方面在返回端口设备之前我们需要保持设备引用以避免调用程序函数中出现 UaF。 (CVE-2025-39872)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mm/damon/sysfs修复 state_show() 中的释放后使用 state_show() 读取 kdamond->damon_ctx 而不持有 damon_sysfs_lock。这样会发生释放后使用争用 CPU 0 CPU 1 ----- ----- state_show() damon_sysfs_turn_damon_on() ctx = kdamond->damon_ctx; mutex_lock(&damon_sysfs_lock);
    damon_destroy_ctx(kdamond->damon_ctx); kdamond->damon_ctx = NULL mutex_unlock(&damon_sysfs_lock);
    damon_is_running(ctx); /* 释放 ctx */ mutex_lock(&ctx->kdamond_lock); /* UAF */ damon_sysfs_kdamonds_rm_dirs() 和 damon_sysfs_kdamond_release() 也可发生争用情形其释放或替换 damon_sysfs_lock 下的上下文。通过在取消引用上下文之前获取 damon_sysfs_lock 来修复此漏洞镜像 pid_show() 中使用的锁定。自 state_show() 首次访问 kdamond->damon_ctx 以来便存在此缺陷。 (CVE-2025-39877)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：drm/mediatek: fix potential OF node use-after-free The for_each_child_of_node() helper drops the reference it takes to each node as it iterates over children and an explicit of_node_put() is only needed when exiting the loop early. Drop the recently introduced bogus additional reference count decrement at each iteration that could potentially lead to a use-after-free. (CVE-2025-39882)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - dmaengineidxd修复 idxd_setup_wqs() 中的双重释放 idxd_setup_wqs() 中的清理存在几个缺陷因为错误处理有些隐蔽。以更清晰的方式重写它会更简单。此处的问题包括1) 如果 idxd->max_wqs <= 0 我们会在 conf_dev 尚未初始化时调用 put_device(conf_dev)。 2) 如果 kzalloc_node() 失败则 conf_dev 也会无效。它未初始化或者指向上一个迭代的 conf_dev从而导致双重释放。最好释放循环内的部分循环迭代，然后在末尾的展开可以处理整个循环迭代。我还对标签进行了重命名以描述 goto 的用途而非 goto 所在的位置。
    (CVE-2025-39870)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - btrfs修复由 inode xarray 争用导致的子卷删除锁定。在 inode 逐出和 inode 缓存之间存在争用条件可造成 root->inodes xarray 中实时结构 btrfs_inode 缺失。具体来说在 evict() 期间在反哈希的 inode 和从 xarray 中删除的 inode 之间存在一个窗口。如果在该窗口中针对相同 inode 调用 btrfs_iget()则该 inode 将被重新创建并插入 xarray 中但随后逐出将删除新的条目而不在 xarray 中留下任何内容线程 1 线程 2 ------- -------------------------------------------------- ------ evict() remove_inode_hash() btrfs_iget_path() btrfs_iget_locked() btrfs_read_locked_inode() btrfs_add_inode_to_root() destroy_inode() btrfs_destroy_inode() btrfs_del_inode_from_root() __xa_erase 而这可导致子卷删除的问题。具体来说如果一个 inode 处于此丢失状态且所有其他 inode 被逐出则 btrfs_del_inode_from_root() 将提前调用 btrfs_add_dead_root()。如果丢失的 inode 附加有 delayed_node则当 btrfs_clean_one_deleted_snapshot() 调用 btrfs_kill_all_delayed_nodes() 时 将永远循环因为 delayed_nodes xarray 将永不为空除非内存压力迫使 inode 出站。我们在生产环境中发现此表现为软锁定。
    修复此问题的方法是仅删除与给定 inode 匹配的 xarray 条目使用 __xa_cmpxchg()。
    (CVE-2025-39884)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - canxilinx_canxcan_write_frame()修复传输的 SKB 的释放后使用 can_put_echo_skb() 占用 SKB 的所有权可能会在调用期间或之后释放。然而xilinx_can xcan_write_frame() 在调用之后保持使用 SKB。通过在代码完成与 SKB 的接触后仅调用 can_put_echo_skb() 来修复此问题。tx_lock 会在整个 xcan_write_frame() 执行期间保留并且在 can_get_echo_skb() 端也会保留因此操作的顺序并不重要。较早的补丁提交 3d3c817c3a40canxilinx_can修复 skb 内存的使用未将 can_put_echo_skb() 调用移动得足够远。 [mkl
    在修补程序描述中的 sha1 前面添加提交] [mkl修复缩进] (CVE-2025-39873)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：ceph: fix crash after fscrypt_encrypt_pagecache_blocks() error The function move_dirty_folio_in_page_array() was created by commit ce80b76dd327 (ceph: introduce ceph_process_folio_batch() method) by moving code from ceph_writepages_start() to this function. This new function is supposed to return an error code which is checked by the caller (now ceph_process_folio_batch()), and on error, the caller invokes redirty_page_for_writepage() and then breaks from the loop. However, the refactoring commit has gone wrong, and it by accident, it always returns 0 (= success) because it first NULLs the pointer and then returns PTR_ERR(NULL) which is always 0. This means errors are silently ignored, leaving NULL entries in the page array, which may later crash the kernel. The simple solution is to call PTR_ERR() before clearing the pointer. (CVE-2025-39878)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：erofs: fix runtime warning on truncate_folio_batch_exceptionals() Commit 0e2f80afcfa6(fs/dax: ensure all pages are idle prior to filesystem unmount) introduced the WARN_ON_ONCE to capture whether the filesystem has removed all DAX entries or not and applied the fix to xfs and ext4. Apply the missed fix on erofs to fix the runtime warning: [ 5.266254] ------------[ cut here ]------------ [ 5.266274] WARNING: CPU: 6 PID: 3109 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xff/0x260 [ 5.266294] Modules linked in: [ 5.266999] CPU: 6 UID: 0 PID: 3109 Comm: umount Tainted: G S 6.16.0+ #6 PREEMPT(voluntary) [ 5.267012] Tainted:
    [S]=CPU_OUT_OF_SPEC [ 5.267017] Hardware name: Dell Inc. OptiPlex 5000/05WXFV, BIOS 1.5.1 08/24/2022 [5.267024] RIP: 0010:truncate_folio_batch_exceptionals+0xff/0x260 [ 5.267076] Code: 00 00 41 39 df 7f 11 eb 78 83 c3 01 49 83 c4 08 41 39 df 74 6c 48 63 f3 48 83 fe 1f 0f 83 3c 01 00 00 43 f6 44 26 08 01 74 df <0f> 0b 4a 8b 34 22 4c 89 ef 48 89 55 90 e8 ff 54 1f 00 48 8b 55 90 [ 5.267083] RSP: 0018:ffffc900013f36c8 EFLAGS: 00010202 [ 5.267095] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 5.267101] RDX: ffffc900013f3790 RSI: 0000000000000000 RDI: ffff8882a1407898 [ 5.267108] RBP: ffffc900013f3740 R08:
    0000000000000000 R09: 0000000000000000 [ 5.267113] R10: 0000000000000000 R11: 0000000000000000 R12:
    0000000000000000 [ 5.267119] R13: ffff8882a1407ab8 R14: ffffc900013f3888 R15: 0000000000000001 [ 5.267125] FS: 00007aaa8b437800(0000) GS:ffff88850025b000(0000) knlGS:0000000000000000 [ 5.267132] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.267138] CR2: 00007aaa8b3aac10 CR3: 000000024f764000 CR4:
    0000000000f52ef0 [ 5.267144] PKRU: 55555554 [ 5.267150] Call Trace: [ 5.267154] <TASK> [ 5.267181] truncate_inode_pages_range+0x118/0x5e0 [ 5.267193] ? save_trace+0x54/0x390 [ 5.267296] truncate_inode_pages_final+0x43/0x60 [ 5.267309] evict+0x2a4/0x2c0 [ 5.267339] dispose_list+0x39/0x80 [5.267352] evict_inodes+0x150/0x1b0 [ 5.267376] generic_shutdown_super+0x41/0x180 [ 5.267390] kill_block_super+0x1b/0x50 [ 5.267402] erofs_kill_sb+0x81/0x90 [erofs] [ 5.267436] deactivate_locked_super+0x32/0xb0 [ 5.267450] deactivate_super+0x46/0x60 [ 5.267460] cleanup_mnt+0xc3/0x170 [ 5.267475] __cleanup_mnt+0x12/0x20 [ 5.267485] task_work_run+0x5d/0xb0 [ 5.267499] exit_to_user_mode_loop+0x144/0x170 [ 5.267512] do_syscall_64+0x2b9/0x7c0 [ 5.267523] ?
    __lock_acquire+0x665/0x2ce0 [ 5.267535] ? __lock_acquire+0x665/0x2ce0 [ 5.267560] ? lock_acquire+0xcd/0x300 [ 5.267573] ? find_held_lock+0x31/0x90 [ 5.267582] ? mntput_no_expire+0x97/0x4e0 [5.267606] ? mntput_no_expire+0xa1/0x4e0 [ 5.267625] ? mntput+0x24/0x50 [ 5.267634] ? path_put+0x1e/0x30 [5.267647] ? do_faccessat+0x120/0x2f0 [ 5.267677] ? do_syscall_64+0x1a2/0x7c0 [ 5.267686] ? from_kgid_munged+0x17/0x30 [ 5.267703] ? from_kuid_munged+0x13/0x30 [ 5.267711] ?
    __do_sys_getuid+0x3d/0x50 [ 5.267724] ? do_syscall_64+0x1a2/0x7c0 [ 5.267732] ? irqentry_exit+0x77/0xb0 [5.267743] ? clear_bhb_loop+0x30/0x80 [ 5.267752] ? clear_bhb_loop+0x30/0x80 [ 5.267765] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 5.267772] RIP: 0033:0x7aaa8b32a9fb [ 5.267781] Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 e9 83 0d 00 f7 d8 [ 5.267787] RSP:
    002b:00007ffd7c4c9468 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 5.267796] RAX: 0000000000000000 RBX:
    00005a61592a8b00 RCX: 00007aaa8b32a9fb [ 5.267802] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
    00005a61592b2080 [ 5.267806] RBP: 00007ffd7c4c9540 R08: 00007aaa8b403b20 R09: 0000000000000020 [ 5.267812] R10: 0000000000000001 R11: 0000000000000246 R12: 00005a61592a8c00 [ 5.267817] R13: 00000000
    ---truncated--- (CVE-2025-39868)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - netfec修复 fec_enet_phy_reset_after_clk_enable() 中可能的 NPD 函数 of_phy_find_device 可能返回 NULL因此取消引用 phy_dev 之前需要注意。 (CVE-2025-39876)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - igb修复 ethtool 环回测试中的空指针取消引用 igb 驱动程序目前在执行 ethtool 环回测试时造成空指针取消引用。出现这种情况的原因是，在设置测试环时没有与之相关的 q_vector，而中断通常不会添加到测试环。由于提交 5ef44b3cb43b 删除了 __xdp_rxq_info_reg() 中的 napi_id 分配不再需要向其传递 napi_id。因此，只需使用 0 作为最后一个参数。 (CVE-2025-39875)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - kernfs修复发布开放文件时轮询中的 UAF 在 PSI 压力失速信息监控机制中发现一个释放后使用 (UAF) 漏洞缺陷KASANpsi_trigger_poll+0x3c 中的 slab-use-after-free /0x140 任务 systemd/1 psi_trigger_poll+0x3c/0x140 cgroup_pressure_poll+0x70/0xa0 cgroup_file_poll+0x8c/0x100 kernfs_fop_poll+0x11c/0x1c0 ep_item_poll.isra.0:AllocatingcbyAllowed: /0x140 地址 ffff3de3d50bd308 中大小 8 的读取
    cgroup_file_open+0x88/0x388 kernfs_fop_open+0x73c/0xaf0 do_dentry_open+0x5fc/0x1200 vfs_open+0xa0/0x3f0 do_open+0x7e8/0xd08 path_openat+0x2fc/0x6b0 do_filp_open+0x174/0x368 由任务 8462 释放
    cgroup_file_release+0x130/0x1f8 kernfs_drain_open_files+0x17c/0x440 kernfs_drain+0x2dc/0x360 kernfs_show+0x1b8/0x288 cgroup_file_show+0x150/0x268 cgroup_pressure_write+0x1dc/0x340 cgroup_file_write+0x274/0x548 Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. 禁用监控echo 0 > test/cgroup.pressure 3. 重新启用监控echo 1 > test/cgroup.pressure 发生争用条件的原因有: 1. 禁用了 cgroup.pressure (echo 0 > cgroup.pressure) - 通过 cgroup_file_release() 释放 PSI 触发器 - 通过 kernfs_drain_open_files() 释放 of->priv 2. epoll 仍保留对文件的引用并继续轮询 3. 重新启用回显 1 > cgroup.pressure访问已释放的->priv epolling 禁用/启用 cgroup.pressure fd=open(cpu.pressure) while(1) ... epoll_wait kernfs_fop_poll kernfs_get_active = true echo 0 > cgroup.pressure ... cgroup_file_show kernfs_show // 不活动的 kn kernfs_drain_open_files cft->release中的
    kfree(ctx); ... kernfs_get_active = false echo 1 > cgroup.pressure kernfs_show kernfs_activate_one(kn);
    kernfs_fop_poll kernfs_get_active = true cgroup_file_poll psi_trigger_poll // UAF ... end: close(fd) 要解决此问题为 kernfs 打开文件引入 kernfs_get_active_of() 以获取活动引用。
    如果打开的文件已发布此函数将失败。将 kernfs_get_active() 替换为 kernfs_get_active_of() 以防止对已释放的文件描述符执行进一步操作。 (CVE-2025-39881)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：macsec: sync features on RTM_NEWLINK Syzkaller managed to lock the lower device via ETHTOOL_SFEATURES: netdev_lock include/linux/netdevice.h:2761 [inline] netdev_lock_ops include/net/netdev_lock.h:42 [inline] netdev_sync_lower_features net/core/dev.c:10649 [inline] __netdev_update_features+0xcb1/0x1be0 net/core/dev.c:10819 netdev_update_features+0x6d/0xe0 net/core/dev.c:10876 macsec_notify+0x2f5/0x660 drivers/net/macsec.c:4533 notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2267 [inline] call_netdevice_notifiers net/core/dev.c:2281 [inline] netdev_features_change+0x85/0xc0 net/core/dev.c:1570 __dev_ethtool net/ethtool/ioctl.c:3469 [inline] dev_ethtool+0x1536/0x19b0 net/ethtool/ioctl.c:3502 dev_ioctl+0x392/0x1150 net/core/dev_ioctl.c:759 It happens because lower features are out of sync with the upper: __dev_ethtool (real_dev) netdev_lock_ops(real_dev) ETHTOOL_SFEATURES __netdev_features_change netdev_sync_upper_features disable LRO on the lower if (old_features != dev->features) netdev_features_change fires NETDEV_FEAT_CHANGE macsec_notify NETDEV_FEAT_CHANGE netdev_update_features (for each macsec dev) netdev_sync_lower_features if (upper_features != lower_features) netdev_lock_ops(lower) # lower == real_dev stuck ... netdev_unlock_ops(real_dev) Per commit af5f54b0ef9e (net: Lock lower level devices when updating features), we elide the lock/unlock when the upper and lower features are synced. Makes sure the lower (real_dev) has proper features after the macsec link has been created. This makes sure we never hit the situation where we need to sync upper flags to the lower. (CVE-2025-39874)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - dmaenginetiedma修复 queue_priority_map 的内存分配大小 修复 edma_setup_from_hw() 中的严重内存分配缺陷即为 queue_priority_map 分配的内存不足。代码将 queue_priority_map 声明为 s8 (*)[2]指向 2 s8 的数组的指针但却使用 sizeof(s8) 而非正确的大小分配内存。这会在访问以下内容时造成越界内存写入
    queue_priority_map[i][0] = i; queue_priority_map[i][1] = i;由于内存损坏触发了 Clang 上的内核强化功能因此在 EDMA 驱动程序探测期间缺陷以 ARM 平台上的 Oops - 未定义指令导致内核崩溃 (BeagleBoard-X15)。更改分配以使用 sizeof(*queue_priority_map)其自动获取 2D 数组结构的正确大小。
    (CVE-2025-39869)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ocfs2修复 fiemap 调用中的递归信号量死锁。syzbot 检测到因特制的 mmap 文件上范围列表的 FS_IOC_FIEMAP 上的递归信号量而导致的 OCFS2 挂起。 context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core .c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/ rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm /memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm /memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [内联] exc_page_fault+0x76/0xf0 arch/x86/mm/fault。 c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include /asm/idtentry.h:623 RIP0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [内联] RIP0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [内联] RIP0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline] RIP0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26 代码e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89 f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 <f3> a4 0f 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 411 5e RSP: 0018:ffffc9000403f950 EFLAGS: 00050256 RAX:
    ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038 RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060 RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42 R10:
     R11dffffc0000000000  : fffff52000807f43 R12: 0000200000000098 R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/ 0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [内联] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [内联] __se_sys_ioctl+0x82/0x170 fs /ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f13850fd9b: RSP: 002b :00007ffe3b3518b8 EFLAGS
    00000246 ORIG_RAX0000000000000010 RAXffffffffffffffda RBX0000200000000000 RCX00007f5f13850fd9 RDX
    0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004 RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0 R13:
    00007ffe3b351b18 R14431bde82d7b634db R1500007f5f1389a03b ocfs2_fiemap() 获取 ip_alloc_sem 信号量的读取锁定(v2.6.22-527-g7307de80510a 起)并调用运行 mmap 的范围的 fiemap_fill_next_extent()。用户提供缓冲区来容纳 fiemap 信息页面错误调用 ocfs2_page_mkwrite() 将采用相同信号量的写入锁定 (v2.6.27-38-g00dc417fa3e7 起)。此递归信号量将保持文件系统锁定并导致文件系统挂起。
    ip_alloc_sem 保护 inode 范围列表和大小。调用 ocfs2_fiemap() 和 ocfs2_fiemap_inline() 中的 fiemap_fill_next_extent() 之前释放读取 semphore。这会在最后一个盘区执行不必要的信号量锁定/解锁但会简化错误路径。 (CVE-2025-39885)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：ceph: always call ceph_shift_unused_folios_left() The function ceph_process_folio_batch() sets folio_batch entries to NULL, which is an illegal state. Before folio_batch_release() crashes due to this API violation, the function ceph_shift_unused_folios_left() is supposed to remove those NULLs from the array. However, since commit ce80b76dd327 (ceph: introduce ceph_process_folio_batch() method), this shifting doesn't happen anymore because the for loop got moved to ceph_process_folio_batch(), and now the `i` variable that remains in ceph_writepages_start() doesn't get incremented anymore, making the shifting effectively unreachable much of the time. Later, commit 1551ec61dc55 (ceph: introduce ceph_submit_write() method) added more preconditions for doing the shift, replacing the `i` check (with something that is still just as broken):
    - if ceph_process_folio_batch() fails, shifting never happens - if ceph_move_dirty_page_in_page_array() was never called (because ceph_process_folio_batch() has returned early for some of various reasons), shifting never happens - if `processed_in_fbatch` is zero (because ceph_process_folio_batch() has returned early for some of the reasons mentioned above or because ceph_move_dirty_page_in_page_array() has failed), shifting never happens Since those two commits, any problem in ceph_process_folio_batch() could crash the kernel, e.g. this way: BUG: kernel NULL pointer dereference, address: 0000000000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 172 UID: 0 PID: 2342707 Comm: kworker/u778:8 Not tainted 6.15.10-cm4all1-es #714 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.10 12/08/2023 Workqueue: writeback wb_workfn (flush-ceph-1) RIP: 0010:folios_put_refs+0x85/0x140 Code: 83 c5 01 39 e8 7e 76 48 63 c5 49 8b 5c c4 08 b8 01 00 00 00 4d 85 ed 74 05 41 8b 44 ad 00 48 8b 15 b0 > RSP: 0018:ffffb880af8db778 EFLAGS: 00010207 RAX:
    0000000000000001 RBX: 0000000000000000 RCX: 0000000000000003 RDX: ffffe377cc3b0000 RSI: 0000000000000000 RDI: ffffb880af8db8c0 RBP: 0000000000000000 R08: 000000000000007d R09: 000000000102b86f R10:
    0000000000000001 R11: 00000000000000ac R12: ffffb880af8db8c0 R13: 0000000000000000 R14: 0000000000000000 R15: ffff9bd262c97000 FS: 0000000000000000(0000) GS:ffff9c8efc303000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000034 CR3: 0000000160958004 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ceph_writepages_start+0xeb9/0x1410 The crash can be reproduced easily by changing the ceph_check_page_before_write() return value to `-E2BIG`. (Interestingly, the crash happens only if `huge_zero_folio` has already been allocated; without `huge_zero_folio`, is_huge_zero_folio(NULL) returns true and folios_put_refs() skips NULL entries instead of dereferencing them. That makes reproducing the bug somewhat unreliable. See https://lore.kernel.org/20250826231626.218675-1-max.kellermann@ionos.com for a discussion of this detail.) My suggestion is to move the ceph_shift_unused_folios_left() to right after ceph_process_folio_batch() to ensure it always gets called to fix up the illegal folio_batch state. (CVE-2025-39879)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已通过改进检查解决正确性问题。此问题已在 Safari 26、iOS 18.7 和 iPadOS 18.7、iOS 26 和 iPadOS 26、macOS Tahoe 26、tvOS 26、visionOS 26、watchOS 26 中修复。处理恶意构建的 Web 内容或可导致进程意外崩溃。(CVE-2025-43342)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已通过改进内存处理解决此问题。此问题已在 Safari 26、iOS 26 和 iPadOS 26、macOS Tahoe 26、visionOS 26、watchOS 26 中修复。处理恶意构建的 Web 内容可能导致 Safari 意外崩溃。(CVE-2025-43272)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已通过改进缓存处理解决此问题。此问题已在 Safari 26、iOS 18.7 和 iPadOS 18.7、iOS 26 和 iPadOS 26、macOS Tahoe 26、tvOS 26、visionOS 26、watchOS 26 中修复。网站可能会在未经用户同意的情况下访问传感器信息。(CVE-2025-43356)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 即使在 safe_mode=True 时Keras Model.load_model 方法也可被利用以实现任意代码执行。可创建特别构建的 .h5/.hdf5 模型存档通过 Model.load_model 加载时将触发执行任意代码。这是通过构建一个特殊的 .h5 存档文件来实现的该文件使用 keras 的 Lambda 层功能其允许 pickle 代码形式的任意 Python 代码。产生该漏洞的原因是读取 .h5 存档时不遵守 safe_mode=True 选项。请注意.h5/.hdf5 格式是 Keras 3 为向后兼容而支持的旧格式。 (CVE-2025-9905)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - Bluetooth修复 l2cap_sock_cleanup_listen() 中的释放后使用 syzbot 报告以下无重现的 splat。在 splat 中调用 bt_accept_dequeue() 的单个线程释放了 sk 并在此后对其进行了触摸。根本原因可能是由引用的提交添加的 racy l2cap_sock_cleanup_listen() 调用。
    bt_accept_dequeue() 会在 lock_sock() 下调用但 l2cap_sock_release() 除外。在 bt_accept_dequeue() 的列表迭代期间两个线程可发现相同的套接字CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- 阻止 close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) 的 refcnt ) <-- last refcnt bt_accept_unlink(sk) <-- UAF 根据时间安排其他线程可能会显示在“由任务释放”部分中。假设在 l2cap_sock_release() 中在 lock_sock() 下调用 l2cap_sock_cleanup_listen()。
    [0]BUGKASANdebug_spin_lock_before kernel/locking/spinlock_debug.c:86 中的 slab-use-after-free [内联] BUGKASANdo_raw_spin_lock+0x26f/0x2b0 kernel/locking/ 中的 slab-use-after-free spinlock_debug.c:115 由任务 syz.5.3276/16995 CPU3 UID: 0 PID16995 Commsyz.5.3276 未受感染 syzkaller #0 PREEMPT(full) 硬件名称QEMU Standard PCQ35 ( ] + ICH92009BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 调用跟踪 <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib /dump_stack.c:120 print_address_description mm/kasan/report.c:378 [内联] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/ locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c 3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2c ap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c 1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common。 c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [内联] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [内联] syscall_exit_to_user_mode include/linux/entry-common.h:210 [内联] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP0033:0x7f2accf8ebe9 代码ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 40 49 49 49 49 49 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP
    002b00007ffdb6cb1378 EFLAGS00000246 ORIG_RAX00000000000001b4 RAX0000000000000000 RBX
    00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11:
     R120000000000000246  : 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK> Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c :68毒害_kmalloc_redzone mm/kasan/common.c:388 [内联] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [内联] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated--- (CVE-2025-39860)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - pcmcia修复了 __iodyn_find_io_region() 中的空指针取消引用 在 __iodyn_find_io_region()中pcmcia_make_resource() 被分配给 res 并用于 pci_bus_alloc_resource()。pci_bus_alloc_resource() 中存在对 res 的取消引用可在 pcmcia_make_resource() 失败时导致空指针取消引用。通过添加 res 的检查修复此缺陷。 (CVE-2025-39846)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - MapServer 是一个用于开发基于 Web 的 GIS 应用程序的系统。在低于 8.4.1的版本中XML Filter Query 指令 PropertyName 容易受到基于布尔值的 SQL 注入的影响。似乎可通过在 PropertyName 中引入双引号字符来绕过表达式检查。允许操纵后端数据库查询。此漏洞已在 8.4.1 中修复。(CVE-2025-59431)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ax25正确取消共享 ax25_kiss_rcv() 中的 skbBernard Pidoux 报告一个明显由提交 c353e8983e0dnet 造成的回归按 netns 数据包链引入。 skb->dev 变为 NULL导致 中崩溃
    __netif_receive_skb_core()。在提交上述行为之前可能会发生严重的缺陷或损坏而不会造成重大崩溃。但根本原因是 ax25_kiss_rcv() 可以在不检查此 skb 是否共享的情况下对输入 skb 进行排队/破坏。非常感谢 Bernard Pidoux 的帮助、诊断和测试。我们有一个类似的问题 多年前已通过提交 7aaed57c5c28phonet正确取消共享phonet_rcv() 中的 skbs进行修复。 (CVE-2025-39848)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - batman-adv修复网络编码解码中的 OOB 读取/写入 batadv_nc_skb_decode_packet() 信任 coded_len 并且仅针对 skb->len 检查。XOR 从 sizeof(struct batadv_unicast_packet) 开始从而减少负载余量并且未验证源 skb 长度从而允许越界读取和少量越界写入。验证 XOR 之前 coded_len 是否适合目标和源 sk_buff 的负载区域。 (CVE-2025-39839)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ocfs2防止在日志关闭之后释放日志 inode 在调用 ocfs2_delete_osb() 之前已在 ocfs2_dismount_volume() 中执行 ocfs2_journal_shutdown()因此 osb->journal 必须为空。因此当以下 calltrace 到达 jbd2_journal_release_jbd_inode() 时将无法避免地失败。 ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()->
    __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal添加 osb->journal 检查将防止在上述执行路径期间发生 null-ptr-deref。(CVE-2025-39842

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 即使在 safe_mode=True 时Keras Model.load_model 方法也可被利用以实现任意代码执行。可创建特别构建的 .keras 模型存档文件通过 Model.load_model 加载时将触发执行任意代码。这是通过构建特殊的 config.json这是 .keras 存档文件内的一个文件将调用 keras.config.enable_unsafe_deserialization() 以禁用安全模式来实现。禁用安全模式后可使用 keras 的 Lambda 层功能这允许 pickle 代码形式的任意 Python 代码。两者可出现在同一存档中。仅 keras.config.enable_unsafe_deserialization() 需要首先出现在存档中并且包含任意代码的 Lambda 需要出现在第二个位置。 (CVE-2025-9906)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - x86/mm/64定义 ARCH_PAGE_TABLE_SYNC_MASK 和 arch_sync_kernel_mappings() 定义 ARCH_PAGE_TABLE_SYNC_MASK 和 arch_sync_kernel_mappings()以确保在调用 p*d_populate_kernel() 时页表正确同步。对于 5 级分页可通过 pgd_populate_kernel() 执行同步。在 4 级分页中pgd_populate() 为 no-op因此转而通过 p4d_populate_kernel() 在 P4D 级别执行同步。此更新修复了使用 4 级分页和大量持久性内存的系统上的间歇性引导失败缺陷 无法处理地址 ffffe70000000034 的页面错误 #PF内核模式 #PF 中的主管写入访问 #PF: error_code(0x0002) - not-当前页 PGD 0 P4D 0 Oops0002 [#1] SMP NOPTI RIP0010:__init_single_page+0x9/0x6d 调用跟踪
    <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus/0x9c... </TASK> xipx9] 它还修复了 vmemmap_set_pmd() 中因在 sync_global_pgds() 之前访问 vmemmap 而造成的崩溃 [1]缺陷无法处理地址的页面错误
    ffffeb3ff1200000 #PF内核模式下的监控程序写入访问 #PFerror_code(0x0002) - not-present page PGD 0 P4D 0 OopsOops0002 [#1] PREEMPT SMP NOPTI Tainted[W]=WARN RIP: 0010:vmemmap_set_pmd +0xff/0x230 <TASK> vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80
    __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/ 0x740 [xe] [... snip ...] (CVE-2025-39845)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - wifimt76mt7915修复硬件重新启动后的列表损坏原因是在调用 ieee80211_restart_hw 之前必须清除所有添加了 wcid 的列表。为每个 wcid 条目设置 wcid->sta = 0 以确保在准备就绪之前不会再次将其添加。
    (CVE-2025-39862)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mm将页面表同步声明移动到 linux/pgtable.h 在内部测试期间当计算机使用 4 级分页并具有大量持久性内存时我们开始观察到间歇性引导失败缺陷无法处理 的页面错误addressffffe70000000034 #PF内核模式下的监控程序写入访问 #PFerror_code(0x0002) - 不存在页 PGD 0 P4D 0 Oops0002 [#1] SMP NOPTI RIP
    0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK> 事实证明当 vmemmap 区域跨越两个 PGD 条目时初始化 vmemmap结构页面数组时会发生内核错误因为新 PGD 条目只安装在 init_mm.pgd 中而未安装在 init_mm.pgd 中。在其他任务的页表中。并查看 __populate_section_memmap() if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // 同步 x86 中的顶级页面表 r = vmemmap_populate(start, end, nid, altmap);在正常路径中arch/x86/mm/init_64.c 中的 vmemmap_populate() 同步顶级页表请参阅提交 9b861528a801 (x86-64、mem更新直接映射和 vmemmap 映射变更的所有 PGD)以便所有系统中的任务可发现新的 vmemmap 区域。但是当 vmemmap_can_optimize() 返回 true 时优化路径会跳过顶层页表的同步。这是因为 vmemmap_populate_compound_pages() 是在核心 MM 代码中实现的而该代码不处理顶级页表的同步。相反，核心 MM 历史上一直依赖每个架构来手动执行此同步。我们不是第一个遇到因未同步的顶级页表而造成的崩溃的人今年早些时候Gwan-geek Mun 在执行 x86 代码时遇到内核错误之后尝试解决问题 [1] [2]在相应的顶级条目同步之前访问了 vmemmap 区域。当时据认为仅当出于调试目的扩大结构页面时才会触发问题并且该补丁未得到进一步更新。事实证明当前依赖每个 arch 手动处理页表同步的方法很不稳定因为 1) 很容易忘记同步顶级页表 2) 也很容易忽略内核不应访问同步前的 vmemmap 和 direct 映射区域。 # 解决方案使页表同步代码更健全更不易遗漏为解决此问题Dave Hansen 建议 [3] [4] 引入 {pgd,p4d}_populate_kernel() 来更新页表的内核部分并允许每个架构在安装顶级条目时明确执行同步。通过此方法，我们无需再担心缺少同步步骤，从而降低了未来发生回归的风险。
    新接口重新使用 vmalloc 和 ioremap 用于同步页表的现有 ARCH_PAGE_TABLE_SYNC_MASK、PGTBL_P*D_MODIFIED 和 arch_sync_kernel_mappings() 设施。
    pgd_populate_kernel() 看起来像这样 static inline void pgd_populate_kernel(unsigned long addr, pgd_t
    *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr);值得注意的是 vmalloc() 和 apply_to_range() 通过调用 p*d_alloc_track() 和 arch_sync_kernel_mappings() 仔细地同步页表因此它们不受 ---truncated--- (CVE-2025-39844)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ptpocp修复由 ptp_ocp_watchdog 造成的释放后使用缺陷 ptp_ocp_detach() 仅会关闭待定的监控程序定时器。但是如果定时器处理程序已在运行则不会调用 timer_delete_sync()。这会导致争用条件其中包含 ptp_ocp 的 devlink 被释放时定时器处理程序仍在访问它从而导致释放后使用缺陷。以下内容详细说明了其中一种争用情况。线程 1|线程 2ptp_ocp_remove() | ptp_ocp_detach() | ptp_ocp_detach() ptp_ocp_watchdog() if (timer_pending(&bp->watchdog))| bp = timer_container_of() timer_delete_sync() | bp | devlink_free(devlink) | bp-> //使用 通过无条件调用 timer_delete_sync() 解决此问题以确保可靠地停用定时器从而防止任何释放后访问。 (CVE-2025-39859)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

远程 Linux 主机上安装了 Aviatrix Cloud Network Controller。

远程主机上安装的 Keycloak 版本低于 26.2.9。因此受到公告 GHSA-wc64-wmfm-46vw 和 GHSA-xmcw-mv9p-7pq2 中提及的多个漏洞的影响。

  - Windows 上 Keycloak 的 Vault 密钥处理中存在路径遍历验证缺陷。之前针对 CVE-2024-10492 的修复未考虑 Windows 文件分隔符 (\)。因此高权限管理员可通过特制的 Vault 密码查找探测是否存在预期领域上下文之外的文件。这是 的平台特定变体/不完整的修复 CVE-2024-10492。 (CVE-2025-10043)

  - 在 Keycloak 中发现一个缺陷。Keycloak 的帐户控制台和其他页面接受 error_description 查询参数中的任意文本。此文本会直接在错误页面中呈现，未经验证或审查。HTML 编码可防止 XSS 的同时攻击者可构建包含误导性消息例如假的支持电话号码或 URL 的 URL这些信息将显示在受信任的 Keycloak UI 中。这会创建钓鱼矢量可能诱骗用户联系恶意执行者。 (CVE-2025-10044)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

因此如公告 APSB25-88 所述远程主机上安装的 Adobe Commerce B2B 版本受到一个漏洞的影响。

  - Adobe Commerce 版本 2.4.9-alpha2、2.4.8-p2、2.4.7-p7、2.4.6-p12、2.4.5-p14、2.4.4-p15 及更早版本会受到不当输入验证漏洞的影响。成功的攻击者可滥用此缺陷实现会话接管、将机密性和完整性影响提升至高。若要利用此问题，并不需要用户交互。(CVE-2025-54236)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程主机上安装的 Adobe Commerce/Magento Open Source 版本因此受到公告 APSB25-88 中提及的一个漏洞的影响。

  - Adobe Commerce 版本 2.4.9-alpha2、2.4.8-p2、2.4.7-p7、2.4.6-p12、2.4.5-p14、2.4.4-p15 及更早版本会受到不当输入验证漏洞的影响。成功的攻击者可滥用此缺陷实现会话接管、将机密性和完整性影响提升至高。若要利用此问题，并不需要用户交互。(CVE-2025-54236)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

在远程主机上检测到 Dell PowerScale OneFS（原名 Isilon OneFS、EMC Isilon OneFS、Dell EMC Isilon OneFS 和 Dell EMC PowerScale OneFS）。

远程主机为 Dell PowerScale 设备（原名 EMC Isilon、Dell EMC Isilon 和 Dell EMC PowerScale）。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - tracing 修复 cpu 缓冲区写入与交换警告之间的争用问题代码处的 rb_end_commit() 中发生 if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))) 警告内核/trace/ 处的 CPU: 0 PID: 139 ring_buffer.c:3142 rb_commit+0x402/0x4a0 调用跟踪 ring_buffer_unlock_commit+0x42/0x250 trace_buffer_unlock_commit_regs+0x3b/0x250 trace_event_buffer_commit+0xe5/0x440 trace_event_buffer_reserve+0x11c/0x150 trace_event_raw_switch+0x2c0x2c0x2c0x2c_event_sched
    __traceiter_sched_switch+0x59/0x80 __schedule+0x72b/0x1580 schedule+0x92/0x120 worker_thread+0xa0/0x6f0 原因是通过文件 per_cpu/cpu0/snapshot 写入 cpu 缓冲区和交换 cpu 缓冲区之间存在争用: 在 CPU 0 交换缓冲区上写入CPU 1 上的 per_cpu/cpu0/snapshot -------- -------- tracing_snapshot_write() [...] ring_buffer_lock_reserve() cpu_buffer = buffer->buffers[cpu]; // 1.假设找到 'cpu_buffer_a'; [...] rb_reserve_next_event() [...] ring_buffer_swap_cpu() if (local_read(&cpu_buffer_a->committing)) goto out_dec; if (local_read(&cpu_buffer_b->committing)) goto out_dec; buffer_a->buffers[cpu] = cpu_buffer_b buffer_b->buffers[cpu] = cpu_buffer_a // 2. cpu_buffer 已交换此处。 rb_start_commit(cpu_buffer); if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) { // 3. 此检查已通过因为“cpu_buffer->buffer”[...] // 未在此处更改。返回 NULL } cpu_buffer_b->buffer = buffer_a; cpu_buffer_a->buffer = buffer_b; [...] // 4. 保留来自“cpu_buffer_a”的事件。 ring_buffer_unlock_commit() [...] cpu_buffer = buffer->buffers[cpu]; // 5. 现在查找“cpu_buffer_b” rb_commit(cpu_buffer) rb_end_commit() // 6. WARN 错误的“提交”状态根据上述分析我们可以通过下面的测试案例轻松重现 `` bash #!/bin/bash dmesg -n 7 sysctl -w kernel.panic_on_warn=1 TR=/sys/kernel/tracing echo 7 > ${TR} /buffer_size_kb echo sched:sched_switch > ${TR}/set_event while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot did & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot did & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot Done & `为了修复此问题IIUC我们可以使用 smp_call_function_single() 在缓冲区所在的目标 cpu 上执行交换因此上述争用被避免的情况。 (CVE-2023-53368)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ubifs释放 tmpfile 名称的内存当打开加密目录中的 ubifs tmpfile 时函数 fscrypt_setup_filename 为要存储在目录条目中的名称分配内存但在将该名称复制到目录条目 inode 后系统将重新分配内存未释放。当在其上运行 kmemleak 时发现其已注册为泄漏。只要打开一个简单的程序 'tmpfile' 即可触发下列报告 a tmpfile: unreferenced object 0xffff88810178f380 (size 32) (size 32): comm tmpfile, pid 509, jiffies 4294934744 (age 1524.742s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename this Freed_openfile memory vubifs_tmpfileafter它已被复制到 inode。 (CVE-2023-53276)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - NVIDIA Mellanox DPDK 在轮询模式驱动程序 (PMD) 中含有漏洞攻击者可在系统中的 VM 上造成网络接口上的信息泄露和拒绝服务。
    (CVE-2025-23259)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - Firefox for Android 中隐私组件中的信息泄露、缓解措施绕过。此漏洞影响 Firefox < 143。(CVE-2025-10535)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：drivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler() Commit 041879b12ddb (drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()) besides fixing the deadlock also modified _rtw_join_timeout_handler() to use spin_[un]lock_irq() instead of spin_[un]lock_bh(). _rtw_join_timeout_handler() calls rtw_do_join() which takes pmlmepriv->scanned_queue.lock using spin_[un]lock_bh(). This spin_unlock_bh() call re-enables softirqs which triggers an oops in kernel/softirq.c: __local_bh_enable_ip() when it calls lockdep_assert_irqs_enabled(): [ 244.506087] WARNING: CPU: 2 PID: 0 at kernel/softirq.c:376
    __local_bh_enable_ip+0xa6/0x100 ... [ 244.509022] Call Trace: [ 244.509048] <IRQ> [ 244.509100]
    _rtw_join_timeout_handler+0x134/0x170 [r8723bs] [ 244.509468] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs] [ 244.509772] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs] [ 244.510076] call_timer_fn+0x95/0x2a0 [ 244.510200] __run_timers.part.0+0x1da/0x2d0 This oops is causd by the switch to spin_[un]lock_irq() which disables the IRQs for the entire duration of _rtw_join_timeout_handler().
    Disabling the IRQs is not necessary since all code taking this lock runs from either user contexts or from softirqs, switch back to spin_[un]lock_bh() to fix this. (CVE-2023-53281)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - recordmcount修复 uwrite 函数中的内存泄漏常见 realloc 错误失败时“file_append”为空但未释放 (CVE-2023-53318)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：wifi: wilc1000: add missing unregister_netdev() in wilc_netdev_ifc_init() Fault injection test reports this issue: kernel BUG at net/core/dev.c:10731! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI Call Trace: <TASK> wilc_netdev_ifc_init+0x19f/0x220 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_cfg80211_init+0x30c/0x380 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_bus_probe+0xad/0x2b0 [wilc1000_spi 1520a7539b6589cc6cde2ae826a523a33f8bacff] spi_probe+0xe4/0x140 really_probe+0x17e/0x3f0 __driver_probe_device+0xe3/0x170 driver_probe_device+0x49/0x120 The root case here is alloc_ordered_workqueue() fails, but cfg80211_unregister_netdevice() or unregister_netdev() not be called in error handling path. To fix add unregister_netdev goto lable to add the unregister operation in error handling path. (CVE-2022-50361)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：fs/ntfs3: Fix null-ptr-deref on inode->i_op in ntfs_lookup() Syzbot reported a null-ptr-deref bug: ntfs3: loop0: Different NTFS' sector size (1024) and media sector size (512) ntfs3: loop0: Mark volume as dirty due to NTFS errors general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:d_flags_for_inode fs/dcache.c:1980 [inline] RIP: 0010:__d_add+0x5ce/0x800 fs/dcache.c:2796 Call Trace: <TASK> d_splice_alias+0x122/0x3b0 fs/dcache.c:3191 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3688 do_filp_open+0x264/0x4f0 fs/namei.c:3718 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline]
    __do_sys_open fs/open.c:1334 [inline] __se_sys_open fs/open.c:1330 [inline] __x64_sys_open+0x221/0x270 fs/open.c:1330 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 If the MFT record of ntfs inode is not a base record, inode->i_op can be NULL. And a null-ptr-deref may happen: ntfs_lookup() dir_search_u() # inode->i_op is set to NULL d_splice_alias() __d_add() d_flags_for_inode() # inode->i_op->get_link null-ptr-deref Fix this by adding a Check on inode->i_op before calling the d_splice_alias() function.
    (CVE-2023-53294)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - caif修复 cfctrl_linkup_request() 中的内存泄漏。当 cfctrl_linkup_request() 中的 linktype 为未知或 kzalloc 失败时未释放 pkt。向错误路径添加发布进程。 (CVE-2023-53330)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mmcwmt-sdmmc修复 mmc_add_host() 的返回值检查 mmc_add_host() 可能返回错误可能如果忽略其返回值在 mmc_alloc_host() 中分配的内存将因删除而泄漏并将导致内核崩溃未在删除路径中添加设备。因此通过检查返回值并转到将调用 mmc_free_host() 的错误路径来修复此问题此外还需要调用 clk_disable_unprepare()。
    (CVE-2022-50353)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：drm/sched: Check scheduler work queue before calling timeout handling During an IGT GPU reset test we see again oops despite of commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling timeout handling). It uses ready condition whether to call drm_sched_fault which unwind the TDR leads to GPU reset. However it looks the ready condition is overloaded with other meanings, for example, for the following stack is related GPU reset : 0 gfx_v9_0_cp_gfx_start 1 gfx_v9_0_cp_gfx_resume 2 gfx_v9_0_cp_resume 3 gfx_v9_0_hw_init 4 gfx_v9_0_resume 5 amdgpu_device_ip_resume_phase2 does the following: /* start the ring */ gfx_v9_0_cp_gfx_start(adev);
    ring->sched.ready = true; The same approach is for other ASICs as well : gfx_v8_0_cp_gfx_resume gfx_v10_0_kiq_resume, etc... As a result, our GPU reset test causes GPU fault which calls unconditionally gfx_v9_0_fault and then drm_sched_fault. However now it depends on whether the interrupt service routine drm_sched_fault is executed after gfx_v9_0_cp_gfx_start is completed which sets the ready field of the scheduler to true even for uninitialized schedulers and causes oops vs no fault or when ISR drm_sched_fault is completed prior gfx_v9_0_cp_gfx_start and NULL pointer dereference does not occur. Use the field timeout_wq to prevent oops for uninitialized schedulers. The field could be initialized by the work queue of resetting the domain. v1: Corrections to commit message (Luben) (CVE-2023-53351)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - btrfs修复 btrfs_cancel_balance 中的 BUG_ON 条件 暂停和取消平衡可争用中断平衡导致 btrfs_cancel_balance 中的 BUG_ON 错误。btrfs_cancel_balance 中的 BUG_ON 条件未考虑此争用情况。但是，争用条件没有其他副作用。我们可以修复该问题。使用如下所示的错误跟踪对其进行重现：kernel BUG at fs/btrfs/volumes.c:4618! RIP
    0010:btrfs_cancel_balance+0x5cf/0x6a0 调用跟踪 <TASK> ? do_nanosleep+0x60/0x120 hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > -------------------- > .......在另一线程中发出暂停和取消 req > ------------ -------- > ret = __btrfs_balance(fs_info); >> mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, balance:暂停); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED);
    > } (CVE-2023-53339)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

ID	名称	严重性
265878	Linux Distros 未修补的漏洞：CVE-2025-39888	high
265877	Linux Distros 未修补的漏洞：CVE-2025-39886	medium
265876	Linux Distros 未修补的漏洞：CVE-2025-39872	medium
265875	Linux Distros 未修补的漏洞：CVE-2025-39877	high
265874	Linux Distros 未修补的漏洞：CVE-2025-39882	high
265873	Linux Distros 未修补的漏洞：CVE-2025-39870	high
265872	Linux Distros 未修补的漏洞：CVE-2025-39884	medium
265871	Linux Distros 未修补的漏洞：CVE-2025-39873	high
265870	Linux Distros 未修补的漏洞：CVE-2025-39878	medium
265869	Linux Distros 未修补的漏洞：CVE-2025-39868	high
265868	Linux Distros 未修补的漏洞：CVE-2025-39876	medium
265867	Linux Distros 未修补的漏洞：CVE-2025-39875	medium
265866	Linux Distros 未修补的漏洞：CVE-2025-39881	high
265864	Linux Distros 未修补的漏洞：CVE-2025-39874	medium
265863	Linux Distros 未修补的漏洞：CVE-2025-39869	high
265862	Linux Distros 未修补的漏洞：CVE-2025-39885	medium
265861	Linux Distros 未修补的漏洞：CVE-2025-39879	medium
265860	Linux Distros 未修补的漏洞：CVE-2025-43342	critical
265859	Linux Distros 未修补的漏洞：CVE-2025-43272	medium
265858	Linux Distros 未修补的漏洞：CVE-2025-43356	medium
265855	Linux Distros 未修补的漏洞：CVE-2025-9905	high
265854	Linux Distros 未修补的漏洞：CVE-2025-39860	high
265853	Linux Distros 未修补的漏洞：CVE-2025-39846	medium
265852	Linux Distros 未修补的漏洞：CVE-2025-59431	critical
265851	Linux Distros 未修补的漏洞：CVE-2025-39848	medium
265850	Linux Distros 未修补的漏洞：CVE-2025-39839	high
265849	Linux Distros 未修补的漏洞：CVE-2025-39842	medium
265848	Linux Distros 未修补的漏洞：CVE-2025-9906	high
265847	Linux Distros 未修补的漏洞：CVE-2025-39845	medium
265846	Linux Distros 未修补的漏洞：CVE-2025-39862	high
265845	Linux Distros 未修补的漏洞：CVE-2025-39844	medium
265844	Linux Distros 未修补的漏洞：CVE-2025-39859	high
265842	安装了 Aviatrix 云网络控制器 (Linux)	info
265769	Keycloak < 26.2.9 多种漏洞 (GHSA-wc64-wmfm-46vw)(GHSA-xmcw-mv9p-7pq2)	medium
265751	Adobe Commerce B2B 不当输入验证APSB25-88	critical
265750	Adobe Commerce/Magento Open Source 不正确的输入验证APSB25-88	critical
265703	Dell PowerScale OneFS 操作系统检测	info
265702	Dell PowerScale 硬件检测	info
265675	Linux Distros 未修补的漏洞：CVE-2023-53368	medium
265674	Linux Distros 未修补的漏洞：CVE-2023-53276	medium
265673	Linux Distros 未修补的漏洞：CVE-2025-23259	medium
265672	Linux Distros 未修补的漏洞：CVE-2025-10535	high
265671	Linux Distros 未修补的漏洞：CVE-2023-53281	medium
265670	Linux Distros 未修补的漏洞：CVE-2023-53318	medium
265669	Linux Distros 未修补的漏洞：CVE-2022-50361	medium
265668	Linux Distros 未修补的漏洞：CVE-2023-53294	medium
265667	Linux Distros 未修补的漏洞：CVE-2023-53330	medium
265666	Linux Distros 未修补的漏洞：CVE-2022-50353	medium
265665	Linux Distros 未修补的漏洞：CVE-2023-53351	medium
265664	Linux Distros 未修补的漏洞：CVE-2023-53339	medium

检测

Nessus 的 Misc. 系列

high

medium

medium

high

high

high

medium

high

medium

high

medium

medium

high

medium

high

medium

medium

critical

medium

medium

high

high

medium

critical

medium

high

medium

high

medium

high

medium

high

info

medium

critical

critical

info

info

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium