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

  - python-socketio 是 Socket.IO 实时客户端和服务器的 Python 实现。在低于 5.14.0 的 python-socketio 版本中存在远程代码执行漏洞，在攻击者此前已获得服务器间用于内部通信的消息队列访问权限的多服务器部署环境中，这个漏洞允许攻击者通过恶意的 pickle 反序列化执行任意 Python 代码。当 Socket.IO 服务器被配置为使用诸如 Redis 之类的消息队列后端来进行服务器间通信时，服务器之间发送的消息是使用 Python 的 pickle 模块进行编码的。当服务器通过消息队列接收到其中一条消息时，它会假定该消息是可信的，并立即对其进行反序列化。漏洞的根源在于使用 Python 的 pickle.loads() 函数对消息进行反序列化。攻击者如果事先获得了对消息队列的访问权限，就可以向 python-socketio 服务器发送特制的 pickle 负载，在反序列化过程中通过 Python 的 __reduce__ 方法执行任意代码。该漏洞仅影响消息队列已遭到入侵的部署环境。此类攻击可能导致攻击者在 Socket.IO 服务器进程的上下文中以其权限执行任意代码。不使用消息队列的单服务器系统，以及使用安全消息队列的多服务器系统，不受此漏洞影响。除了确保在消息队列部署中遵循标准安全实践外，python-socketio 包的用户还可以升级到 5.14.0 或更新的版本，该版本移除了对 pickle 模块的使用，并改用安全性更高的 JSON 编码进行服务器间消息传递。(CVE-2025-61765)

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

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

  - xen/gntdev适应 VMA 拆分在此提交之前gntdev 驱动程序代码未正确处理使用半虚拟化 (PV) Xen 域的以下情况* 用户进程建立一个由两个授权映射组成的 gntdev 映射即两个页面由另一个 Xen 域共享。 * 用户进程 munmap()s 页面之一。 * 用户进程 munmap()s 剩余的页面。 * 用户进程退出。在上述情况中用户进程可导致内核在第一个 munmap() 的 dmesg 中记录以下消息而第二个 munmap() 调用将导致类似的日志消息缺陷:进程 doublemap.test 中存在错误页面映射pte:... pmd:... page:0000000057c97bff refcount:1 mapcount:-1 \ mapping:0000000000000000 index:0x0 pfn:... ... 页面转储原因是 pte 不良 ... file:gntdev 错误: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 管理程序如果使用 CONFIG_DEBUG 构建都会打印出以下内容并在受影响的 Xen PV 域中触发一般保护错误(XEN) d0v... 尝试隐式取消映射 d0 的 grant PTE ... (XEN) d0v... 尝试隐式取消映射 d0 的 grant PTE ... 在撰写本文时gntdev_grant_map 结构的 vma 字段下面称为 map->vma主要用于检查映射的起始和结束地址。但是，对于拆分的 VMA，这些情况可能会发生变化，并且可能有多个 VMA 与 gntdev 映射关联。因此删除使用 map->vma并针对原始起始地址依赖 map->pages_vm_start以及针对原始映射大小依赖 (map->count << PAGE_SHIFT)。让 invalidate() 和 find_special_page() 挂钩使用这些函数。此外考虑到可能存在与 gntdev 映射关联的多个 VMA请将 mmu_interval_notifier_remove(&map->notifier) 调用移动到 gntdev_put_map 的末尾以便仅在关闭最后一个剩余 VMA 后删除 MMU 通知程序。最后使用 atomic 来防止无意的 gntdev 映射重新使用而不是使用 map->live_grants 原子计数器和/或 map->vma 指针后者现已被删除。这可以防止用户空间通过 MAP_FIXED对与之前设置的 gntdev 映射相同的地址范围内的 gntdev 映射进行 mmap()处理。此场景可概括为下列调用跟踪其在此提交之前有效 mmap gntdev_mmap mmap在相同地址范围内使用 MAP_FIXED 重复 mmapgntdev_invalidate unmap_grant_pages将 'making_removed' 条目设置为 truegnttab_unmap_refs_async unmap_single_vma gntdev_mmap munmap gntdev_invalidate unmap_grant_pagesno-op因为“making_removed”条目为 trueunmap_single_vma对于 PV 域Xen 报告授予的页面正在被取消映射如果构建了 Xen则在受影响的域中触发一般保护错误和 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_vectors 并将无效指针留在 dev->napi_list 中。Re Producer[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)) ; return 1 } ifconfig $nic 192.168.18.5 网络掩码 255.255.255.0 ifconfig $nic up ethtool -L $nic 合并 1 ethtool -L $nic 合并 4睡眠 $((RANDOM%3)) } function on_exit() { ${g_pids[@]} 中 pid 的本地 pid; do kill -0 $pid &>/dev/null && kill $pid &>/dev/null did g_pids=() } trap on_exit;
    退出 EXIT while :;执行 do_set_numvf ; did & g_pids+=($!) while :;执行 do_set_channel ; did & g_pids+=($!) 等待结果 [ 4093.900222] =================================== =============================== [4093.900230] BUGKASANfree_netdev+0x308/0x390 中的释放后使用[ 4093.900232] 由任务 repro.sh/6699 在 addr ffff88b4dc145640 读取大小 8 [ 4093.900233] [ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump:已加载 Tainted: GO ------- -- -t - 4.18.0 #1 [ 4093.900238] Hardware name: Powerheader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021 [ 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] RIP0033:0x7f16ad4d22c0 [ 4093.900359] 代码73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c3 66 ff 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 通过可视化工具包 (VTK) 的接口提供 3D 绘图和网格分析。
    PyVista 项目 0.46.3 版本容易受到通过依存关系混淆导致的远程代码执行的影响。两段代码使用--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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ARMdtsexynos对 MIPI 视频 phy 使用 Exynos5420 兼容版本。由于某些原因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 可能返回空指针因此最好检查返回值以避免空指针取消引用这一点与其他操作相同。
    (CVE-2022-50501)

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

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

  - nilfs2修复 nilfs_sb2_bad_offset() 修补程序系列中的位移越界/溢出 nilfs2修复挂载时的 UBSAN 位移越界警告。第一个修补程序修复了 syzbot 报告的一个缺陷第二个修补程序修复了其余的同类型缺陷。虽然这两个问题由相同的超级块数据异常触发，但我将其拆分为上述两个问题，因为问题的详细信息及其修复方式不同。需要两者兼有才能消除挂载时的位移越界问题。此修补程序共 2 个修补程序
    如果写入磁盘上超级块的块大小指数信息损坏nilfs_sb2_bad_offset 辅助函数可触发位移越界警告然后发生内核错误如果设置 panic_on_warn位移指数 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/nilfs2 /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 变体解码的数据可能大于为其分配的缓冲区。使用编解码器 48 编码的帧可以指定其分辨率（宽 x 高）。根据分辨率分配适当大小的缓冲区。此编解码器可使用游程编码算法对帧内容进行编码。不检查解码的帧是否适合分配的缓冲区从而导致堆缓冲区溢出。 process_frame_obj 会根据帧分辨率初始化缓冲区我们建议升级到版本 8.0 或更高版本。 (CVE-2025-59730)

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

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

  - 可能使用低于 2 的 subversion 在带有精心构建动画的 SANM 解码中造成释放后使用写入。存在 STOR 区块时后续的 FOBJ 区块将保存在 ctx->stored_frame 中。
    存储的帧随后可被 FTCH 区块引用。对于使用低于 2 的 subversion 的文件系统会存储未解码的帧并在解析 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 依赖供应商报告的程序包是否存在进行判断。

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

  - 已修复 Linux 内核中的下列漏洞：crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390 Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point to the scatterlist array in areq->first_rsgl.sgl.sgl. Without this, the gcm-aes-s390 driver will oops when it tries to do gcm_walk_start() on req->dst because req->dst is set to the value of areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling aead_request_set_crypt(). The problem comes if an empty ciphertext is passed: the loop in af_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl up. This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far as I can tell, that ignores req->dst and only uses req->src[*]. [*] Is this a bug in aesni-intel_glue.c? The s390x oops looks something like: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000a00000000 TEID: 0000000a00000803 Fault in home space mode while using kernel ASCE.
    AS:00000000a43a0007 R3:0000000000000024 Oops: 003b ilc:2 [#1] SMP ... Call Trace: [<000003ff7fc3d47e>] gcm_walk_start+0x16/0x28 [aes_s390] [<00000000a2a342f2>] crypto_aead_decrypt+0x9a/0xb8 [<00000000a2a60888>] aead_recvmsg+0x478/0x698 [<00000000a2e519a0>] sock_recvmsg+0x70/0xb0 [<00000000a2e51a56>] sock_read_iter+0x76/0xa0 [<00000000a273e066>] vfs_read+0x26e/0x2a8 [<00000000a273e8c4>] ksys_read+0xbc/0x100 [<00000000a311d808>] __do_syscall+0x1d0/0x1f8 [<00000000a312ff30>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003ff7fc3e6b4>] gcm_aes_crypt+0x104/0xa68 [aes_s390] (CVE-2023-53599)

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

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

  - ocfs2: fix defrag path triggering jbd2 ASSERT code path: ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERT crash stacks: PID: 11297 TASK:
    ffff974a676dcd00 CPU: 67 COMMAND: defragfs.ocfs2 #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op@ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op@ffffffff84200d18 [exception RIPjbd2_journal_dirty_metadata+0x2ba] RIPffffffffc09ca54a RSP
    ffffb25d8dad3b70 RFLAGS00010207 RAX0000000000000000 RBXffff9706eedc5248 RCX0000000000000000 RDX
    0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13:
    0000000000000000 R14ffff9703de59bf60 R15ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc135fb95 #8 [bed] 38ffb95]
    __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2] Analysis This bug has the same root cause of 'commit 7f27ec978b0e (ocfs2: call ocfs2_journal_access_di() before ocfs2_journal_dirty() in ocfs2_write_end_nolock())'. 对于此缺陷在碎片整理期间由 ocfs2_split_extent() 调用 jbd2_journal_restart()。如何修复 For ocfs2_split_extent() 完全无法自行处理日志操作。调用方无需调用日志访问/脏对调用方仅需要调用日志对开始/停止。修复方法是从 __ocfs2_move_extent() 中删除 journal access/dirty。此修补程序的讨论
    https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html (CVE-2023-53564)

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

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

  - 在计算 MPEG-DASH 清单处理中的内容路径时发现存在越界空字节写入超出缓冲区末尾一个字节的情况。当调用低于 [0] 的 xmlNodeGetContent 时它返回的缓冲区精确分配到匹配字符串长度在内部使用 strdup。如果此缓冲区不是空字符串则将其分配给 [1] 处的 root_url。如果此缓冲区中的最后一个非空字节不是“/”则我们在 [2] 处就地附加“/”。这会将两个字节写入缓冲区从缓冲区中的最后一个有效字节开始将空字节写入超出分配的缓冲区末尾。建议升级到版本 8.0 或更高版本。 (CVE-2025-59728)

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

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

  - zram修复插槽写入争用条件 对相同 zram 索引的并行并发写入会导致 zsmalloc 句柄泄露。我们可以拥有如下原理图 CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock() compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle句柄 zram_slot_lock CPU0 或 CPU1 zsmalloc 句柄将泄漏因为 zs_free() 过早完成。实际上我们需要在设置 zram 条目的新句柄之前重置 zram 条目所有操作都在同一个插槽锁定范围下。 (CVE-2025-39941)

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

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

  - drm/amdgpu终止 gfx_v11_0_cp_ecc_error_irq_funcs gfx.cp_ecc_error_irq 已在 gfx11 中停用。在 gfx_v11_0_hw_fini 中仍然使用 amdgpu_irq_put 来禁用此中断从而导致此函数中存在调用跟踪。 [ 102.873958] 调用跟踪[ 102.873959] <TASK> [ 102.873961] gfx_v11_0_hw_fini+0x23/0x1e0 [amdgpu] [ 102.874019] gfx_v11_0_suspend+0xe/0x20 [amdgpu] [ 102.874072] amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu] [ 102.874122] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu] [ 102.874172] amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu] [ 102.874223] amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu] [ 102.874321] amdgpu_debugfs_reset_work+0x70 [amdgpu_debugfs_reset_work+0x70] [ 102.874375] process_one_work+0x21f/0x3f0 [ 102.874377] worker_thread+0x200/0x3e0 [ 102.874378] ? process_one_work+0x3f0/0x3f0 [ 102.874379] kthread+0xfd/0x130 [ 102.874380] ? kthread_complete_and_exit+0x20/0x20 [ 102.874381] ret_from_fork+0x22/0x30 v2- 处理分离修补程序中的 umc 和 gfx ras 情况 - 停用 gfx11 v3 中的 gfx_v11_0_cp_ecc_error_irq_funcs - 改善主题和代码注释 - 添加对 函数中 gfx11 的判断amdgpu_gfx_ras_late_init v4 - 终止在 gfx_v11_0_set_cp_ecc_error_state 中使用的 CP_ME1_PIPE_INST_ADDR_INTERVAL 和 SET_ECC_ME_PIPE_STATE 的定义 - 检查 cp_ecc_error_irq.funcs 而非 ip 版本以获得更可持续的寿命 v5- 简化判断条件 (CVE-2023-53628)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/i915/perf: add sentinel to xehp_oa_b_counters Arrays passed to reg_in_range_table should end with empty record. The patch solves KASAN detected bug with signature: BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915] Read of size 4 at addr ffffffffa1555d90 by task perf/1518 CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1 Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023 Call Trace: <TASK> ... xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915] (cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798) (CVE-2023-53646)

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

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

  - ext4修复 ext4_fc_record_regions() 中潜在的内存泄漏由于 krealloc 可能返回 NULL在此情况下“state->fc_regions”可能没有被 krealloc 释放但“state->fc_regions”已设置为 NULL。然后 将导致“state->fc_regions”内存泄漏。 (CVE-2022-50512)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/mlx5e: Take RTNL lock when needed before calling xdp_set_features() Hold RTNL lock when calling xdp_set_features() with a registered netdev, as the call triggers the netdev notifiers. This could happen when switching from uplink rep to nic profile for example. This resolves the following call trace: RTNL: assertion failed at net/core/dev.c (1953) WARNING: CPU: 6 PID: 112670 at net/core/dev.c:1953 call_netdevice_notifiers_info+0x7c/0x80 Modules linked in: sch_mqprio sch_mqprio_lib act_tunnel_key act_mirred act_skbedit cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress bonding ib_umad ip_gre rdma_ucm mlx5_vfio_pci ipip tunnel4 ip6_gre gre mlx5_ib vfio_pci vfio_pci_core vfio_iommu_type1 ib_uverbs vfio mlx5_core ib_ipoib geneve nf_tables ip6_tunnel tunnel6 iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded:
    ib_uverbs] CPU: 6 PID: 112670 Comm: devlink Not tainted 6.4.0-rc7_for_upstream_min_debug_2023_06_28_17_02 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org04/01/2014 RIP: 0010:call_netdevice_notifiers_info+0x7c/0x80 Code: 90 ff 80 3d 2d 6b f7 00 00 75 c5 ba a1 07 00 00 48 c7 c6 e4 ce 0b 82 48 c7 c7 c8 f4 04 82 c6 05 11 6b f7 00 01 e8 a4 7c 8e ff <0f> 0b eb a2 0f 1f 44 00 00 55 48 89 e5 41 54 48 83 e4 f0 48 83 ec RSP: 0018:ffff8882a21c3948 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: ffffffff82e6f880 RCX: 0000000000000027 RDX: ffff88885f99b5c8 RSI: 0000000000000001 RDI: ffff88885f99b5c0 RBP: 0000000000000028 R08: ffff88887ffabaa8 R09: 0000000000000003 R10:
    ffff88887fecbac0 R11: ffff88887ff7bac0 R12: ffff8882a21c3968 R13: ffff88811c018940 R14: 0000000000000000 R15: ffff8881274401a0 FS: 00007fe141c81800(0000) GS:ffff88885f980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f787c28b948 CR3: 000000014bcf3005 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x79/0x120 ? call_netdevice_notifiers_info+0x7c/0x80 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? call_netdevice_notifiers_info+0x7c/0x80 ? call_netdevice_notifiers_info+0x7c/0x80 call_netdevice_notifiers+0x2e/0x50 mlx5e_set_xdp_feature+0x21/0x50 [mlx5_core] mlx5e_nic_init+0xf1/0x1a0 [mlx5_core] mlx5e_netdev_init_profile+0x76/0x110 [mlx5_core] mlx5e_netdev_attach_profile+0x1f/0x90 [mlx5_core] mlx5e_netdev_change_profile+0x92/0x160 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core] mlx5e_vport_rep_unload+0xaa/0xc0 [mlx5_core]
    __esw_offloads_unload_rep+0x52/0x60 [mlx5_core] mlx5_esw_offloads_rep_unload+0x52/0x70 [mlx5_core] esw_offloads_unload_rep+0x34/0x70 [mlx5_core] esw_offloads_disable+0x2b/0x90 [mlx5_core] mlx5_eswitch_disable_locked+0x1b9/0x210 [mlx5_core] mlx5_devlink_eswitch_mode_set+0xf5/0x630 [mlx5_core] ? devlink_get_from_attrs_lock+0x9e/0x110 devlink_nl_cmd_eswitch_set_doit+0x60/0xe0 genl_family_rcv_msg_doit.isra.0+0xc2/0x110 genl_rcv_msg+0x17d/0x2b0 ? devlink_get_from_attrs_lock+0x110/0x110 ? devlink_nl_cmd_eswitch_get_doit+0x290/0x290 ? devlink_pernet_pre_exit+0xf0/0xf0 ? genl_family_rcv_msg_doit.isra.0+0x110/0x110 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1f6/0x2c0 netlink_sendmsg+0x232/0x4a0 sock_sendmsg+0x38/0x60 ?
    _copy_from_user+0x2a/0x60 __sys_sendto+0x110/0x160 ? __count_memcg_events+0x48/0x90 ? handle_mm_fault+0x161/0x260 ? do_user_addr_fault+0x278/0x6e0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033 ---truncated--- (CVE-2023-53632)

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

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

  - srcu如果使用 SRCU_SIZE_SMALL则将工作委派给引导 cpu Commit 994f706872e6srcu使树 SRCU 能够在没有 snp_node 数组的情况下运行假设 cpu 0 始终在线。但是，确实存在某些其他 CPU 成为引导 CPU 的情况，例如，以 maxcpus=1 引导参数引导 kdump 内核时。在 PowerPC 上kdump 内核可挂起如下 ... [ 1.740036] systemd[1]
    主机名设置为 <xyz.com> [ 243.686240] INFO任务 systemd:1 阻止超过 122 秒。 [243.686264] 未受感染 6.1.0-rc1 #1 [ 243.686272] echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 [ 243.686281] task:systemd state:D stack:0 pid:1 ppid:0 flags:0x00042000 [243.686296] Call Trace [ 243.686301] [c000000016657640] [c000000016657670] 0xc000000016657670 (unreliable) [ 243.686317] [c000000016]6 [c00000001001dec0] __switch_to+0x130/0x220 [ 243.686333] [c000000016657890] [c000000010f607b8] __schedule+0x1f8/0x580 [ 243.686347] [c000000016657940] [c000000010f60bb4] schedule+0x74/0x140 [ 243.686361] [c0000000166579b0] [c000000010f699b8] schedule_timeout+ 0x168/0x1c0 [ 243.686374] [c000000016657a80] [c000000010f61de8]
    __wait_for_common+0x148/0x360 [ 243.686387] [c000000016657b20] [c000000010176bb0]
    __flush_work.isra.0+0x1c0/0x3d0 [ 243.686401] [c000000016657bb0] [c0000000105f2768] fsnotify_wait_marks_destroyed+0x28/0x40 [ 243.686415] [c000000016657bd0] [c0000000105f21b8] fsnotify_destroy_group+0x68/0x160 [ 243.686428] [c000000016657c40] [c0000000105f6500] inotify_release +0x30/0xa0 [ 243.686440] [c000000016657cb0] [c0000000105751a8] __fput+0xc8/0x350 [243.686452] [c000000016657d00] [c00000001017d524] task_work_run+0xe4/0x170 [ 243.686464] [c000000016657d50] [c000000010020e94] do_notify_resume+0x134/0x140 [ 243.686478] [c000000016657d80] [c00000001002eb18] interrupt_exit_user_prepare_main+0x198/0x270 [ 243.686493] [c000000016657de0] [c00000001002ec60] syscall_exit_prepare+0x70/0x180 [ 243.686505] [c000000016657e10] [c00000001000bf7c] system_call_vectored_common+0xfc/0x280 [ 243.686520] -- - interrupt: 3000 at 0x7fffa47d5ba4 [ 243.686528] NIP: 00007fffa47d5ba4 LR: 0000000000000000 CTR: 0000000000000000 [ 243.686538] REGS: c000000016657e80 TRAP: 3000 Not tainted (6.1.0-rc1) [ 243.686548] MSR: 800000000000d033<SF,EE,PR,ME,IR,DR,RI,LE> CR
    42044440 XER: 00000000 [ 243.686572] IRQMASK: 0 [ 243.686572] GPR00: 0000000000000006 00007ffffa606710 00007fffa48e7200 0000000000000000 [ 243.686572] GPR04: 0000000000000002 000000000000000a 0000000000000000 0000000000000001 [ 243.686572] GPR08: 000001000c172dd0 0000000000000000 0000000000000000 0000000000000000 [ 243.686572] GPR12: 0000000000000000 00007fffa4ff4bc0 0000000000000000 0000000000000000 [ 243.686572] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 243.686572] GPR20:
    0000000132dfdc50 000000000000000e 0000000000189375 0000000000000000 [ 243.686572] GPR24: 00007ffffa606ae0 0000000000000005 000001000c185490 000001000c172570 [ 243.686572] GPR28: 000001000c172990 000001000c184850 000001000c172e00 00007fffa4fedd98 [ 243.686683] NIP [00007fffa47d5ba4] 0x7fffa47d5ba4 [ 243.686691] LR [0000000000000000] 0x0 [ 243.686698] --- Interrupt: 3000 [ 243.686708] INFO任务 kworker/u16:1:24 阻止超过 122 秒。 [ 243.686717] 未受感染 6.1.0-rc1 #1 [ 243.686724] echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 [ 243.686733] task:kworker/u16:1 state:D stack:0 pid:24 ppid:2 flags:0x00000800 [ 243.686747] Workqueue:events_unbound fsnotify_mark_destroy_workfn [ 243.686758] 调用跟踪[ 243.686762] [c0000000166736e0] [c00000004fd91000 ] 0xc00000004fd91000 (不可靠) [ 243.686775] [c0000000166738d0] [c00000001001dec0]
    __switch_to+0x130/0x220 [ 243.686788] [c000000016673930] [c000000010f607b8] __schedule+0x1f8/0x
    ---truncated--- (CVE-2023-53671)

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

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

  - 已修复 Linux 内核中的下列漏洞：bpf, cpumap: Handle skb as well when clean up ptr_ring The following warning was reported when running xdp_redirect_cpu with both skb-mode and stress-mode enabled: ------------[ cut here ]------------ Incorrect XDP memory type (-2128176192) usage WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405 Modules linked in: CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events
    __cpu_map_entry_free RIP: 0010:__xdp_return+0x1e4/0x4a0 ...... Call Trace: <TASK> ? show_regs+0x65/0x70 ?
    __warn+0xa5/0x240 ? __xdp_return+0x1e4/0x4a0 ...... xdp_return_frame+0x4d/0x150
    __cpu_map_entry_free+0xf9/0x230 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> The reason for the warning is twofold. One is due to the kthread cpu_map_kthread_run() is stopped prematurely. Another one is __cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in ptr_ring as XDP frames. Prematurely-stopped kthread will be fixed by the preceding patch and ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But as the comments in __cpu_map_ring_cleanup() said, handling and freeing skbs in ptr_ring as well to catch any broken behaviour gracefully. (CVE-2023-53660)

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

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

  - netcdc_ncm处理过低的 dwNtbOutMaxSize 值。目前在 cdc_ncm_check_tx_max() 中如果 dwNtbOutMaxSize 小于计算的最小值但大于零则逻辑将 tx_max 设置为 dwNtbOutMaxSize。然后将其用于在处理所有数据的 cdc_ncm_fill_tx_frame() 中分配新的 SKB。对于小 dwNtbOutMaxSize 值在 alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) 期间分配的内存将具有相同大小这是因为分配时大小的对齐方式所致 size = SKB_DATA_ALIGN(size); size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));因此我们遇到了尝试通过提交 2be6d4d16a084 进行压缩的相同缺陷 (netcdc_ncm允许未设置 dwNtbOutMaxSize 或将其设置为零) dwNtbOutMaxSize 的低值不会造成目前的问题因为在 alloc_skb() 时间更多内存 (512b) 被占用分配的内存不足单独为 SKB 标头 (320b) 所需的内存，从而为 CDC 数据 (172b) 留出一些空间 (512b - 320b = 192b)。但是如果更多元素例如 3 x u64 = [24b]被添加到其中一个 SKB 标头结构例如“struct skb_shared_info”会将其原始大小 (320b [320b aligned]) 增加到某个更大的值 (344b [384b aligned]) aligned]然后备用 SKB 数据区域 (512b - 384b = 128b) 突然不再容纳 CDC 数据 (172b)。因此 SKB 边界检查语义失败并产生错误
    skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL> ------------[ 在此处剪切 ]----- ------- 位于 net/core/skbuff.c:113! 的内核缺陷无效 opcode0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 57 Comm: kworker/0:2 未受感染 5.15.106-syzkaller-00249-g19c0ed55a470 #0 硬件名称Google Google Compute Engine/Google Compute Engine、BIOS Google 2023 年 4 月 14 日 Workqueuemld mld_ifc_work RIP: 0010:skb_panic net/core/skbuff.c:113 [inline] RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118 [snip] 调用跟踪 <TASK> skb_put+0x151/0x210 net/core/skbuff.c:2047 skb_put_zero include/linux/skbuff.h:2422 [内联] cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [内联] cdc_ncm_fill_tx_frame+0x11ab/0x3da0 驱动程序/net/usb/cdc_ncm.c:1308 cdc_ncm_tx_fixup+0xa3/0x100 处理 dwNtbOutMaxSize 的过低值，并将其限制在 [USB_CDC_NCM_NTB_MIN_OUT_SIZE、CDC_NCM_NTB_MAX_SIZE_TX] 范围内。我们确保 dwNtbOutMaxSize 不小于 USB_CDC_NCM_NTB_MIN_OUT_SIZE从而确保分配足够的数据空间来处理 CDC 数据。
    (CVE-2023-53667)

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

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

  - bnxt避免 bnxt_get_nvram_directory() 中的溢出 算术表达式的值可能有溢出这是因为执行算术前无法将操作数转换为更大的数据类型所致。
    使用宏进行乘法运算而非运算符以避免溢出。由 Security Code and Linux Verification Center (linuxtesting.org) 通过 SVACE 发现。 (CVE-2023-53661)

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

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

  - 已修复 Linux 内核中的下列漏洞：RDMA/rxe: Fix mr->map double free rxe_mr_cleanup() which tries to free mr->map again will be called when rxe_mr_init_user() fails: CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x5d panic+0x19e/0x349 end_report.part.0+0x54/0x7c kasan_report.cold+0xa/0xf rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe] __rxe_cleanup+0x10a/0x1e0 [rdma_rxe] rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe] ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1397/0x15a0 [ib_uverbs] This issue was firstly exposed since commit b18c7da63fcb (RDMA/rxe: Fix memory leak in error path code) and then we fixed it in commit 8ff5f5d9d8cf (RDMA/rxe: Prevent double freeing rxe_map_set()) but this fix was reverted together at last by commit 1e75550648da (Revert RDMA/rxe: Create duplicate mapping tables for FMRs) Simply let rxe_mr_cleanup() always handle freeing the mr->map once it is successfully allocated. (CVE-2022-50543)

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

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

  - 已修复 Linux 内核中的下列漏洞：nvme-core: fix dev_pm_qos memleak Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to avoid following kmemleak:- blktests (master) # kmemleak-clear; ./check nvme/044; blktests (master) # kmemleak-scan ; kmemleak-show nvme/044 (Test bi-directional authentication) [passed] runtime 2.111s ... 2.124s unreferenced object 0xffff888110c46240 (size 96): comm nvme, pid 33461, jiffies 4345365353 (age 75.586s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000069ac2cec>] kmalloc_trace+0x25/0x90 [<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100 [<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core] [<000000007df61b4b>] 0xffffffffc05e88b3 [<00000000d152b985>] 0xffffffffc05744cb [<00000000f04a4041>] vfs_write+0xc5/0x3c0 [<00000000f9491baf>] ksys_write+0x5f/0xe0 [<000000001c46513d>] do_syscall_64+0x3b/0x90 [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc (CVE-2023-53670)

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

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

  - dmaenginetik3-udma重置 UDMA_CHAN_RT 字节计数器以防止溢出 UDMA_CHAN_RT_*BCNT_REG 存储实时通道字节计数统计数据。这些寄存器是 32 位硬件计数器驱动程序使用这些计数器监控通道的操作进度状态当传输超过 4GB 的数据时发现这些计数器溢出导致操作的完成计算受到影响且传输挂起无限期终止。此提交添加了更改以减少每个完整事务的字节计数以便这些寄存器永远不会溢出并且 RT 计数器为正在进行的事务维护正确的字节计数统计数据。早前uc->bcnt 用于维护驱动程序端的已完成字节计数由于 RT 计数器现在维护当前事务的统计数据因此没有必要维护 uc->bcnt。 (CVE-2022-50541)

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

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

  - ext4修复“ext4_evict_inode”中未初始化的值 Syzbot 发现的以下问题
    ================================================== === BUGKMSANext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 evict+0x365/0x9a0 fs/inode.c 中的 uninit-value 664 iput_final fs/inode.c:1747 [内联] iput+0x985/0xdd0 fs/inode.c:1773
    __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844 vfs_mknod+0x79d/0x830 fs/namei.c:3914 do_mknodat+0x47d/0xaa_fs/namei.c:3914 do_mknodat+0x47d/0xaa_name_sys/name_sys/name_sys/name_sys/name c:3992 [内联]
    __se_sys_mknodat fs/namei.c:3989 [内联] __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [内联] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/mon .c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit 创建于__alloc_pages+0x9f1/ 0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x1b5/0x1010 mm/slub.c:1939 new_slab mm/slub.c 1992 [内联] ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180 __slab_alloc mm/slub.c:3279 [内联] slab_alloc_node mm/slub.c:3364 [内联] slab_alloc mm/slub.c:3406 [内联] __kmem_cache_alloc_lru mm/slub.c:3413 [内联] kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3117 [内联] ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321 alloc_inode +0x83/0x440 fs/inode.c:259 new_inode_pseudo fs/ino de.c:1018 [inline] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959 ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992 vfs_mkdir+ 0x62a/0x870 fs/namei.c:4035 do_mkdirat+0x466/0x7b0 fs/namei.c:4060 __do_sys_mkdirat fs/namei.c:4075 [内联] __se_sys_mkdirat fs/namei.c:4073 [内联] __ia32_sys_mkdirat+0xc4/0x120 fs /namei.c:4073 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [内联] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common。 c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 CPU:1 PID:4625 Commsyz-executor.2 未受感染 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0 硬件名称Google Google Compute Engine/Google Compute EngineBIOS Google 10/26/2022 ============================= ======================== 现在“ext4_alloc_inode()”不会初始化“ei->i_flags”。如果新 inode 在“__ext4_new_inode()”中设置“ei->i_flags”之前失败则执行“iput()”。在 6bc0d63dad7f 提交之后将访问“ext4_evict_inode()”中的“ei->i_flags”这将导致访问 uninit-value。要解决上述问题只需初始化“ext4_alloc_inode()”中的“ei->i_flags”。 (CVE-2022-50546)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: mac80211: mlme: fix null-ptr deref on failed assoc If association to an AP without a link 0 fails, then we crash in tracing because it assumes that either ap_mld_addr or link 0 BSS is valid, since we clear sdata->vif.valid_links and then don't add the ap_mld_addr to the struct. Since we clear also sdata->vif.cfg.ap_addr, keep a local copy of it and assign it earlier, before clearing valid_links, to fix this. (CVE-2022-50533)

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

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

  - ASoC lpass针对 KASAN use_after_free 越界的补丁运行 syzkaller 时会出现下列越界错误。KASANregcache_flat_read 中的 slab 越界读取以下是问题的回溯缺陷缺陷
    KASANslab 越界在 regcache_flat_read+0x10c/0x110 中在地址 ffffff8088fbf714 进行大小 4 的读取由任务 syz-executor.4/14144 CPU: 6 PID: 14144 Comm: syz-executor.4 感染: GW 硬件名称Qualcomm Technologies, Inc. sc7280 CRD 平台 (rev5+) (DT) 调用跟踪 dump_backtrace+0x0/0x4ec show_stack+0x34/0x50 dump_stack_lvl+0xdc/0x11c print_address_description+0x30/0x2d8 kasan_report+0x178/0x1e4 __asan_report_load4_readcachecreg/0x50reg/reg /0x110 regcache_read+0xf8/0x5a0 _regmap_read+0x45c/0x86c _regmap_update_bits+0x128/0x290 regmap_update_bits_base+0xc0/0x15c snd_soc_component_update_bits+0xa8/0x22c snd_soc_component_write_field+0x68/0xd4 tx_macro_put_dec_enum+0x1d0/0x268 snd_ctl_elem_write+0x288/0x474 By Error checking and checking valid values issue正得到整改。 (CVE-2023-53640)

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

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

  - 已修复 Linux 内核中的下列漏洞：clk: Fix memory leak in devm_clk_notifier_register() devm_clk_notifier_register() allocates a devres resource for clk notifier but didn't register that to the device, so the notifier didn't get unregistered on device detach and the allocated resource was leaked. Fix the issue by registering the resource through devres_add(). This issue was found with kmemleak on a Chromebook. (CVE-2023-53674)

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

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

  - 已修复 Linux 内核中的下列漏洞：mm/huge_memory: do not clobber swp_entry_t during THP split The following has been observed when running stressng mmap since commit b653db77350c (mm: Clear page->private when splitting or migrating a page) watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546] CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374 Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016 RIP: 0010:xas_descend+0x28/0x80 Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2 RSP: 0018:ffffbbf02a2236a8 EFLAGS:
    00000246 RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002 RDX: 0000000000000030 RSI:
    ffff9cab60509b60 RDI: ffffbbf02a2236c0 RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0 R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000 R13: ffff9cab4e28da80 R14:
    0000000000039c01 R15: ffff9cab4e28da88 FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fab84e00000 CR3:
    00000040b73a4003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xas_load+0x3a/0x50
    __filemap_get_folio+0x80/0x370 ? put_swap_page+0x163/0x360 pagecache_get_page+0x13/0x90
    __try_to_reclaim_swap+0x50/0x190 scan_swap_map_slots+0x31e/0x670 get_swap_pages+0x226/0x3c0 folio_alloc_swap+0x1cc/0x240 add_to_swap+0x14/0x70 shrink_page_list+0x968/0xbc0 reclaim_page_list+0x70/0xf0 reclaim_pages+0xdd/0x120 madvise_cold_or_pageout_pte_range+0x814/0xf30 walk_pgd_range+0x637/0xa30 __walk_page_range+0x142/0x170 walk_page_range+0x146/0x170 madvise_pageout+0xb7/0x280 ? asm_common_interrupt+0x22/0x40 madvise_vma_behavior+0x3b7/0xac0 ? find_vma+0x4a/0x70 ? find_vma+0x64/0x70 ? madvise_vma_anon_name+0x40/0x40 madvise_walk_vmas+0xa6/0x130 do_madvise+0x2f4/0x360 __x64_sys_madvise+0x26/0x30 do_syscall_64+0x5b/0x80 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? do_syscall_64+0x67/0x80 ? common_interrupt+0x8b/0xa0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The problem can be reproduced with the mmtests config config-workload-stressng-mmap. It does not always happen and when it triggers is variable but it has happened on multiple machines. The intent of commit b653db77350c patch was to avoid the case where PG_private is clear but folio->private is not-NULL. However, THP tail pages uses page->private for swp_entry_t if folio_test_swapcache() as stated in the documentation for struct folio. This patch only clobbers page->private for tail pages if the head page was not in swapcache and warns once if page->private had an unexpected value. (CVE-2022-50517)

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

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

  - 已修复 Linux 内核中的下列漏洞：firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe() In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will not be freed through rpi_firmware_delete(), fix this leak by calling kfree() in the error path.
    (CVE-2022-50537)

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

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

  - bpf、sockmap修复 msg 具有more_data 时对 sock_put() 的重复调用。在 tcp_bpf_send_verdict() 重定向中eval 变量会在发送 apply_bytes 数据后分配给 __SK_REDIRECT如果 msg 具有more_datasock_put() 将被调用多次。我们应在每次more_data 启动时将 eval 变量重置为 __SK_NONE。这会导致IPv4尝试释放状态 1 00000000b4c925d7 中的 TCP 套接字
    ------------[ cut here ]------------ refcount_t0 上的加法释放后使用。WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_slurate+0x7d/0x110 模块中链接的 CPU: 5 PID: 4482 Comm
    sockhash_bypass Kdump已加载未受感染 6.0.0 #1 硬件名称Red Hat KVM、BIOS 1.11.0-2.el7 04/01/2014 调用跟踪 <TASK> __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ?
    __kmalloc_node_track_caller+0x184/0x320 tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640 tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x40/? preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70 __sys_sendto+0xfa/0x170 xfd_validate_state+0x1d/0x80 switch_fpu_return+0x59/0xe0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-50536)

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

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

  - 已修复 Linux 内核中的下列漏洞：tcp: fix skb_copy_ubufs() vs BIG TCP David Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy using hugepages, and skb length bigger than ~68 KB. skb_copy_ubufs() assumed it could copy all payload using up to MAX_SKB_FRAGS order-0 pages. This assumption broke when BIG TCP was able to put up to 512 KB per skb. We did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45 and limit gso_max_size to 180000. A solution is to use higher order pages if needed. v2: add missing __GFP_COMP, or we leak memory. (CVE-2023-53669)

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

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

  - wifiath6kl将回调中的 WARN 减少到 dev_dbg() 已知的争用条件会触发警告已正确处理在上述测试的代码中均有记载。使用 WARN() 会阻碍自动化测试。
    降低严重性。 (CVE-2023-53639)

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

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

  - tun修复分离的 NAPI 队列的内存泄漏。 syzkaller 报告与未重现的 TUN 设备相关的 sk 和 skb 的 [0] 内存泄漏但我们可以通过struct ifreq ifr = {} int fd_tun, fd_tmp; 轻松重现char buf[4] = {} fd_tun = openat(AT_FDCWD, /dev/net/tun, O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | ifr.ifr_flags IFF_NAPI | IFF_MULTI_QUEUE ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE;
    ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP;
    ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)); close(fd_tun);如果在 TUN 设备上启用 NAPI 和多队列我们可在分离队列后将 skb 放入 tfile->sk.sk_write_queue。我们应通过在排队 skb 之前检查 tfile->detached 来防止此问题发生。请注意此操作必须在 tfile->sk.sk_write_queue.lock 下完成因为 write() 和 ioctl(IFF_DETACH_QUEUE) 可同时运行。否则会出现小争用窗口write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb) 另一个解决方案是在关闭并重新连接已分离的队列时调用 tun_queue_purge() 但此方式可能会掩盖另一个问题。此外我们对 IFF_NAPI_FRAGS 进行了同样的测试。 [0] 未引用的对象 0xffff88801edbc800 (大小 2048)comm syz-executor.1、pid 33269、jiffies 4295743834 (age 18.756s) 十六进制转储前 32 字节00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .. .backtrace[<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [内联] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [内联] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>tun_chr_open+0x3d/0x190 drivers/net/tun.c 3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c 920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [内联] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [内联] [<00000000057be699>] __se_sys_openat fs /open.c:1383 [inline] [<00000000057be699>]
    __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c 80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc 未引用对象 0xffff88802f671700(大小 240)comm syz-executor.1, pid 33269, jiffies 4295743854(age 18.736s) hex 转储前 32 字节68 c9 db 80db 81e ff ff 68 c9 db 1e 80 88 ff ff h....h....00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff .. ....... backtrace[<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+ 0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [内联] [< ---truncated--- (CVE-2023-53685)

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

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

  - 已修复 Linux 内核中的下列漏洞：tipc: fix a null-ptr-deref in tipc_topsrv_accept syzbot found a crash in tipc_topsrv_accept: KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipc_rcv tipc_topsrv_accept RIP:
    0010:kernel_accept+0x22d/0x350 net/socket.c:3487 Call Trace: <TASK> tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 It was caused by srv->listener that might be set to null by tipc_topsrv_stop() in net .exit whereas it's still used in tipc_topsrv_accept() worker. srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add a check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to avoid the null-ptr-deref. To ensure the lsock is not released during the tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop() where it's waiting until the tipc_topsrv_accept worker to be done. Note that sk_callback_lock is used to protect sk->sk_user_data instead of srv->listener, and it should check srv in tipc_topsrv_listener_data_ready() instead. This also ensures that no more tipc_topsrv_accept worker will be started after tipc_conn_close() is called in tipc_topsrv_stop() where it sets sk->sk_user_data to null. (CVE-2022-50555)

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

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

  - 已修复 Linux 内核中的下列漏洞：ext4: fix possible double unlock when moving a directory (CVE-2023-53626)

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

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

  - blk-iolatency修复 add_disk() 失败时的内存泄漏当 gendisk 已成功初始化但 add_disk() 失败时例如当循环设备指定了无效数量的次要设备编号时在 init 期间调用 blkcg_init_disk()然后调用 blkcg_exit_disk() ) 在错误处理期间。遗憾的是 iolatency 在前者中得到初始化但在后者中未清除。这是因为在非错误情况下由 del_gendisk() 调用 rq_qos_exit() 执行假设假设仅可在磁盘完全注册且可见后激活 rq_qos 策略iolatency 即其中之一。该假设适用于 wbt 和 iocost，但适用于 iolatency 则不适用，因为它会在调用 add_disk() 之前对其进行初始化。建议对 rq_qos 策略进行 lazy-init因为它们是可选功能并且在初始化后会添加热路径开销 - 每个 IO 都必须遍历所有已注册的 rq_qos 策略。因此我们也希望将 iolatency 切换为 lazy init。但是，这是一个较大的更改。作为针对当前问题的补丁我们仅在 blkcg_exit_disk() 的 rq_qos_exit() 中添加一个额外调用。这样做是安全的因为重复的 rq_qos_exit() 调用会变为 noop。 (CVE-2022-50550)

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

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

  - drm/amdgpu修复非独占域的大小验证 (v4) 修复了 amdgpu_bo_validate_size() 以检查所请求内存的 TTM 域管理器是否存在否则我们会在取消引用 man 时得到内核 oops。 v2使修补程序独立即不依赖于本地修补程序。 v3保留旧行为并仅检查管理器指针是否非 NULL。 v4如果 GTT 域请求且未初始化则投诉--most 可能是一个缺陷。 (CVE-2022-50527)

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

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

  - btrfs如果未能找到内联 backref [缺陷] Syzbot 报告 lookup_inline_extent_backref() 内触发了多个警告。[原因] 和往常一样重现程序不会在此处可靠地触发但至少我们知道找不到内联 backref 时会触发 WARN_ON()并且仅当 @insert 为 true 时才能触发。即插入新的内联 backref即 backref 应已存在[增强] 在 WARN_ON() 后转储所有参数和范围树状结构以帮助调试。 (CVE-2023-53672)

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

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

  - blk-mq重新初始化队列时使用静止的 elevator 开关。在重新初始化硬件队列时hctx 的 run_work 可能与 elevator 开关争用。队列在此上下文中仅被冻结但这仅会阻止请求分配而不会停止 hctx 工作的运行。此工作可能会获得正在被拆除的 elevator 指针，并可导致释放后使用错误和内核错误（示例如下）。改用停顿的 elevator 开关，并将前一个开关设为静态，因为它现在仅在本地使用。 nvme nvme0重置控制器 nvme nvme032/0/0 default/read/poll 队列缺陷
    内核空指针取消引用地址0000000000000008 #PF内核模式下的主管读取访问 #PF
    error_code(0x0000) - not-present 页面 PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops
    0000 [#1] SMP PTI Workqueuekblockd blk_mq_run_work_fn RIP0010:kyber_has_work+0x29/0x70 ... 调用跟踪：
    __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0 (CVE-2022-50552)

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

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

  - ring-buffer修复读取 trace_pipe 时发生的死循环问题。读取文件“trace_pipe”时发生软锁定
    watchdog缺陷软锁定 - CPU#6 卡住 22 秒[cat:4488] [...] RIP
    0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI:
    ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15:
    0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3:
    000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:
    __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ?
    __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 我发现在 tracing_read_pipe() 中ring_buffer_empty_cpu() 发现某个缓冲区非空但之后无法读取任何内容这是因为 rb_num_of_entries() == 0 始终为真然后会由于未填充用户缓冲区而无限循环程序请参阅以下代码 pathtracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. 在此查找非空缓冲区 trace_find_next_entry_inc( ) // 2. 在此处循环尝试查找条目 __find_next_entry() ring_buffer_empty_cpu(); // 3. 查找非空缓冲区 peek_next_entry() // 4. 但扫视始终返回 NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. 由于 rb_num_of_entries() == 0 始终为真 // 则返回 NULL / / 6. 用户缓冲区未填充因此 goto 'waitgain' // 最终导致内核中的死循环通过一些分析我发现重置 ringbuffer 时其页面的“entries”并未全部清除请参阅 rb_reset_cpu()。然后在还原环形缓冲区时如果还原的页面存在脏“entries”数据将被添加到“cpu_buffer->overrun”中请参阅 rb_remove_pages()造成错误的“overrun”计数并最终导致死循环问题。要修复此问题需要清除 rb_reset_cpu() 中的每个页面。 (CVE-2023-53668)

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

ID	名称	严重性
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
269295	Linux Distros 未修补的漏洞：CVE-2023-53599	medium
269294	Linux Distros 未修补的漏洞：CVE-2023-53564	medium
269293	Linux Distros 未修补的漏洞：CVE-2025-59728	high
269292	Linux Distros 未修补的漏洞：CVE-2025-39941	medium
269291	Linux Distros 未修补的漏洞：CVE-2023-53628	medium
269290	Linux Distros 未修补的漏洞：CVE-2023-53646	high
269289	Linux Distros 未修补的漏洞：CVE-2022-50512	medium
269288	Linux Distros 未修补的漏洞：CVE-2023-53632	medium
269287	Linux Distros 未修补的漏洞：CVE-2023-53671	medium
269286	Linux Distros 未修补的漏洞：CVE-2023-53660	medium
269285	Linux Distros 未修补的漏洞：CVE-2023-53667	medium
269284	Linux Distros 未修补的漏洞：CVE-2023-53661	high
269283	Linux Distros 未修补的漏洞：CVE-2022-50543	high
269282	Linux Distros 未修补的漏洞：CVE-2023-53670	medium
269281	Linux Distros 未修补的漏洞：CVE-2022-50541	high
269280	Linux Distros 未修补的漏洞：CVE-2022-50546	high
269279	Linux Distros 未修补的漏洞：CVE-2022-50533	medium
269278	Linux Distros 未修补的漏洞：CVE-2023-53640	high
269277	Linux Distros 未修补的漏洞：CVE-2023-53674	medium
269276	Linux Distros 未修补的漏洞：CVE-2022-50517	high
269275	Linux Distros 未修补的漏洞：CVE-2022-50537	medium
269274	Linux Distros 未修补的漏洞：CVE-2022-50536	medium
269273	Linux Distros 未修补的漏洞：CVE-2023-53669	medium
269272	Linux Distros 未修补的漏洞：CVE-2023-53639	high
269271	Linux Distros 未修补的漏洞：CVE-2023-53685	medium
269270	Linux Distros 未修补的漏洞：CVE-2022-50555	medium
269269	Linux Distros 未修补的漏洞：CVE-2023-53626	high
269268	Linux Distros 未修补的漏洞：CVE-2022-50550	medium
269267	Linux Distros 未修补的漏洞：CVE-2022-50527	medium
269266	Linux Distros 未修补的漏洞：CVE-2023-53672	medium
269265	Linux Distros 未修补的漏洞：CVE-2022-50552	high
269264	Linux Distros 未修补的漏洞：CVE-2023-53668	high

检测

Nessus 的 Misc. 系列

medium

high

high

medium

critical

high

high

medium

medium

medium

high

medium

high

medium

medium

high

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium

medium

medium

high

high

medium

high

high

medium

high

medium

high

medium

medium

medium

high

medium

medium

high

medium

medium

medium

high

high