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

  - 已修复 Linux 内核中的下列漏洞：xen/gntdev: Prevent leaking grants Prior to this commit, if a grant mapping operation failed partially, some of the entries in the map_ops array would be invalid, whereas all of the entries in the kmap_ops array would be valid. This in turn would cause the following logic in gntdev_map_grant_pages to become invalid: for (i = 0; i < map->count;
    i++) { if (map->map_ops[i].status == GNTST_okay) { map->unmap_ops[i].handle = map->map_ops[i].handle; if (!use_ptemod) alloced++; } if (use_ptemod) { if (map->kmap_ops[i].status == GNTST_okay) { if (map->map_ops[i].status == GNTST_okay) alloced++; map->kunmap_ops[i].handle = map->kmap_ops[i].handle; } }} ... atomic_add(alloced, &map->live_grants); Assume that use_ptemod is true (i.e., the domain mapping the granted pages is a paravirtualized domain). In the code excerpt above, note that the alloced variable is only incremented when both kmap_ops[i].status and map_ops[i].status are set to GNTST_okay (i.e., both mapping operations are successful). However, as also noted above, there are cases where a grant mapping operation fails partially, breaking the assumption of the code excerpt above. The aforementioned causes map->live_grants to be incorrectly set. In some cases, all of the map_ops mappings fail, but all of the kmap_ops mappings succeed, meaning that live_grants may remain zero. This in turn makes it impossible to unmap the successfully grant-mapped pages pointed to by kmap_ops, because unmap_grant_pages has the following snippet of code at its beginning: if (atomic_read(&map->live_grants) == 0) return; /* Nothing to do */ In other cases where only some of the map_ops mappings fail but all kmap_ops mappings succeed, live_grants is made positive, but when the user requests unmapping the grant-mapped pages,
    __unmap_grant_pages_done will then make map->live_grants negative, because the latter function does not check if all of the pages that were requested to be unmapped were actually unmapped, and the same function unconditionally subtracts data->count (i.e., a value that can be greater than map->live_grants) from map->live_grants. The side effects of a negative live_grants value have not been studied. The net effect of all of this is that grant references are leaked in one of the above conditions. In Qubes OS v4.1 (which uses Xen's grant mechanism extensively for X11 GUI isolation), this issue manifests itself with warning messages like the following to be printed out by the Linux kernel in the VM that had granted pages (that contain X11 GUI window data) to dom0: g.e. 0x1234 still pending, especially after the user rapidly resizes GUI VM windows (causing some grant-mapping operations to partially or completely fail, due to the fact that the VM unshares some of the pages as part of the window resizing, making the pages impossible to grant-map from dom0). The fix for this issue involves counting all successful map_ops and kmap_ops mappings separately, and then adding the sum to live_grants. During unmapping, only the number of successfully unmapped grants is subtracted from live_grants. The code is also modified to check for negative live_grants values after the subtraction and warn the user. (CVE-2022-50257)

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

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

  - trace/fgraph修复由缺少取消注册通知程序引起的警告此警告在 v6.16 上测试期间触发了通知程序回调 ftrace_suspend_notifier_call 已注册警告CPU2 PID
    86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... 调用跟踪 <TASK> locking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f 写入 function_profile_enabled 接口时在 start_graph_tracing 失败后未取消注册通知器导致下次写入 function_profile_enabled 时发出警告。已通过在异常路径中添加 unregister_pm_notifier 进行修复。 (CVE-2025-39829)

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

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

  - 已修复 Linux 内核中的下列漏洞：erofs: fix order >= MAX_ORDER warning due to crafted negative i_size As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly. Let's fall back to the generic path to deal with such unusual i_size. [1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com (CVE-2022-50313)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs When (size != 0 || ptrs->lvds_ entries != 3), the program tries to free() the ptrs.
    However, the ptrs is not created by calling kzmalloc(), but is obtained by pointer offset operation. This may lead to memory leaks or undefined behavior. Fix this by replacing the arguments of kfree() with ptrs_block. (cherry picked from commit 7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec) (CVE-2022-50287)

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

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

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

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

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

  - 已修复 Linux 内核中的下列漏洞：net: do not sense pfmemalloc status in skb_append_pagefrags() skb_append_pagefrags() is used by af_unix and udp sendpage() implementation so far.
    In commit 326140063946 (tcp: TX zerocopy should not sense pfmemalloc status) we explained why we should not sense pfmemalloc status for pages owned by user space. We should also use skb_fill_page_desc_noacc() in skb_append_pagefrags() to avoid following KCSAN report: BUG: KCSAN: data-race in lru_add_fn / skb_append_pagefrags write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:323 [inline] lru_add_fn+0x327/0x410 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 lru_add_drain_cpu+0x73/0x250 mm/swap.c:669 lru_add_drain+0x21/0x60 mm/swap.c:773 free_pages_and_swap_cache+0x16/0x70 mm/swap_state.c:311 tlb_batch_pages_flush mm/mmu_gather.c:59 [inline] tlb_flush_mmu_free mm/mmu_gather.c:256 [inline] tlb_flush_mmu+0x5b2/0x640 mm/mmu_gather.c:263 tlb_finish_mmu+0x86/0x100 mm/mmu_gather.c:363 exit_mmap+0x190/0x4d0 mm/mmap.c:3098 __mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copy_process+0x19fc/0x2100 kernel/fork.c:2518 kernel_clone+0x166/0x550 kernel/fork.c:2671 __do_sys_clone kernel/fork.c:2812 [inline] __se_sys_clone kernel/fork.c:2796 [inline]
    __x64_sys_clone+0xc3/0xf0 kernel/fork.c:2796 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1817 [inline]
    __skb_fill_page_desc include/linux/skbuff.h:2432 [inline] skb_fill_page_desc include/linux/skbuff.h:2453 [inline] skb_append_pagefrags+0x210/0x600 net/core/skbuff.c:3974 unix_stream_sendpage+0x45e/0x990 net/unix/af_unix.c:2338 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1255
    __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline]
    __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed:
    0x0000000000000000 -> 0xffffea00058fc188 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 (CVE-2022-50323)

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

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

  - 由于 IP 地址值 0 未通过 isPublic 正确分类为可全局路由因此一直使用到 2.0.1 在 NPM 中的 ip又称为 node-ip程序包可能允许 SSRF。注意：存在此问题的原因是对 CVE-2024-29415 的修复不完整。注意在多个应用程序的当前版本中对 IP 地址 0 (解释为 0.0.0.0) 的连接尝试遭到 net::ERR_ADDRESS_INVALID 等错误消息阻断。
    但是在某些同时依赖于应用程序版本和操作系统的情况下对 0 和 0.0.0.0 的连接尝试被视为对 127.0.0.1 的连接尝试正因为此原因isPublic 的错误值会更好。 (CVE-2025-59437)

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

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

  - 在 NPM 中低于 2.0.1 的 ip又称为 node-ip程序包可能允许 SSRF因为 IP 地址值 017700000001 通过 isPublic 被错误地归类为全局可路由。注意：存在此问题的原因是对 CVE-2024-29415 的修复不完整。(CVE-2025-59436)

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

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

  - 已修复 Linux 内核中的下列漏洞：netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong `CIDR_POS(c)` for calculating array offsets, which can lead to integer underflow. As a result, it leads to slab out-of-bound access. This patch adds back the IP_SET_HASH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue. (CVE-2023-53179)

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

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

  - rtcmsc313修复 msc313_rtc_probe() 中的函数原型不匹配。利用 clang 内核控制流完整性kCFI、CONFIG_CFI_CLANG会针对预期函数指针原型验证间接调用目标以确保调用目标有效从而帮助缓解 ROP 攻击。如果它们不同，则运行时会出错，表现为内核错误或线程被终止。 msc313_rtc_probe() 直接传递 clk_disable_unprepare()该函数不具有 devm_add_action_or_reset() 的回调参数的匹配原型。重构以改用 devm_clk_get_enabled()。这是由于 Clang 的新 -Wcast-function-type-strict 标记比更简单的 -Wcast-function-type 仅检查类型宽度不匹配更敏感所导致。
    (CVE-2022-50322)

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

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

  - udf修复以 开头的文件名的某些路径名的未初始化的数组访问。和 的长度在 2 到 5 个字符之间因此 UDF 字符集转换代码将读取输出缓冲区中的未初始化内存。
    唯一的实际影响是当实际不需要时可能会在名称前面预加统一哈希但仍然建议修复此问题。 (CVE-2023-53165)

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

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

  - 已修复 Linux 内核中的下列漏洞：media: airspy: fix memory leak in airspy probe The commit ca9dc8d06ab6 (media: airspy: respect the DMA coherency rules) moves variable buf from stack to heap, however, it only frees buf in the error handling code, missing deallocation in the success path. Fix this by freeing buf in the success path since this variable does not have any references in other code. (CVE-2022-50326)

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

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

  - 已修复 Linux 内核中的下列漏洞：lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts Restore the SIMD usability check that was removed by commit 773426f4771b (crypto: arm/poly1305 - Add block-only interface). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. (CVE-2025-39802)

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

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

  - bpf修复因 fentry 附加失败而造成的内存泄漏如果附加 fentry 失败分配的 bpf trampoline 图像将保留在系统中。这可通过检查 /proc/kallsyms 进行验证。此内存泄露可通过简单的 bpf 程序验证如下所示 SEC(fentry/trap_init) int fentry_run() { return 0; }它将无法附加 trap_init因为此函数在内核初始化后被释放然后我们可以通过检查 /proc/kallsyms 发现 trampoline 图像留在系统中。 $ tail /proc/kallsyms ffffffffc0613000t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000t bpf_trampoline_6442453466_1 [bpf] $ bpftool btf 转储文件/sys/kernel/btf/vmlinux | $ tail /proc/kallsyms ffffffffc0613000t bpf_trampoline_6442453466_1 grep FUNC 'trap_init' [2522] FUNC 'trap_init' type_id=119 linkage=static $ echo $((6442453466 & 0x7fffffff)) 2522 请注意还存在两个 bpf trampoline 图像因为如果返回 -EINVAL则 libbpf 将回退到原始跟踪点。
    (CVE-2023-53221)

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

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

  - ttypcn_uart使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput() 否则随着时间的推移将泄漏内存。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53173)

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

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

  - regulatorcore修复处理 boot-on 时的 use_count 泄漏 我发现具有 boot-on 选项的 rdev 的电源调节器存在 use_count 泄漏。调节器_dev A调节器_dev B (boot-on) (boot-on) use_count=0 provides use_count=1 如果 rdev(A) 配置了“regulator-boot-on”则提供调节器(B) 的 use_count 将在 regulator_enable 内递增(rdev->supply)。因此B 将像 always-on 一样运行进一步平衡调节器启用/禁用实际上无法再将其禁用。
    然而 B 也配置了“regulator-boot-on”我们希望之后能够将其禁用。
    (CVE-2022-50250)

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

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

  - 已修复 Linux 内核中的下列漏洞：driver core: location: Free struct acpi_pld_info *pld before return false struct acpi_pld_info *pld should be freed before the return of allocation failure, to prevent memory leak, add the ACPI_FREE() to fix it. (CVE-2023-53211)

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

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

  - netopenvswitch修复端口输出上的争用假设在单机上进行以下设置 1. 具有一个桥接和默认流的 openvswitch 实例 2. 两个网络命名空间服务器和客户端 3.
    网桥上的两个 ovs 接口服务器和客户端 4. 为每个 ovs 接口准备一个 veth 对，并包含匹配的名称和 32 个 rx 和 tx 队列 5. 将 veth 对的末端移动到相应的网络命名空间 6. 为每个 分配 IP 地址以命名空间结尾的 veth需要为相同的子网 7. 在服务器网络命名空间上启动某个 http 服务器 8. 测试客户端命名空间中的客户端在遵循主机下的操作时是否可以访问 http 服务器有机会的 cpu 卡在无限循环中的步骤1. 发送大量并行请求到 http 服务器大约 3000 curl 应能工作2. 并行删除网络命名空间不删除接口或停止服务器而只是终止命名空间）极低的机率这将导致以下内核 cpu 卡住消息。如果未发生此情况请重试。下面还有输出中提及的函数的 bpftrace 输出。此处发生的一系列事件为1. 会在进程中的某处调用“unregister_netdevice_many_notify”删除网络命名空间 2. 在 veth 的两端首先设置“NETREG_UNREGISTERING”然后运行“synchronize_net” 3. 然后调用“call_netdevice_notifiers” ` 4。此问题然后由调用“ovs_netdev_detach_dev”的“dp_device_event”进行处理如果找到 vport，即附加到 ovs 的 veth 接口的情况5。这会删除设备的 rx_handlers，但不阻止将程序包发送到设备 6. “dp_device_event”然后将 vport 删除排入队列以便在后台工作，因为我们没有在取消注册路径中保留需要的 ovs_lock 7. “unregister_netdevice_many_notify”继续调用设置“netdev_unregister_kobject”的“netdev_unregister_kobject”将 real_num_tx_queues 设置为 0 8. 端口删除会继续但详细信息与此问题无关9. 在未来的某个时候后台任务会删除 7. 之后 9. 之前的 vport If。一个数据包被发送到 ovs vport在这个时间点未被删除即使设备正在取消注册ovs vport也会将其转发到 `dev_queue_xmit` 流。在 `skb_tx_hash`在 `dev_queue_xmit` 路径中调用存在一个 while 循环如果数据包记录了 rx_queue当 `dev->real_num_tx_queues` 为零时该循环是无限的。为防止发生这种情况我们更新了“do_output”以按照与未找到设备相同的方式处理没有运营商的设备这将是 9. 完成之后的代码路径。此外，如果我们现在遇到无限循环，我们现在会在“skb_tx_hash”中生成警告。 bpftrace第一个单词是函数名称
    __dev_queue_xmit serverreal_num_tx_queues1，cpu:2，pid:28024，tid:28024，skb_addr:
    0xffff9edb6f207000reg_state: 1 netdev_core_pick_tx serveraddr: 0xffff9f0a46d4a000 real_num_tx_queues
    1, cpu2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 dp_device_event server
    real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1 Synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited, cpu 9pid 9 21024、tid21024 synchronize_rcu_expeditedcpu 9、pid21024、tid21024 dp_device_event serverreal_num_tx_queues: 1 cpu 9、pid:21024、tid21024、event 6、reg_state:2 ovs_netdev_detach_dev server:1, pid21024、tid21024、reg_state
    2 netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 netdev_rx_handler_unregister ret server
    real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 dp_ ---truncated--- (CVE-2023-53188)

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

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

  - xfrm在 xfrm_update_ae_params 中添加了。但是xfrm_new_ae(...) 的当前实现允许恶意用户直接取消引用空指针并造成内核崩溃如下所示。BUG：
    内核空指针取消引用地址0000000000000000 PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0 Oops
    0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8 硬件名称QEMU Standard PC (i440FX + PIIX,1996)BIOS 相关1.16.0-0-gd239552ce722-prebuilt.qemu.o4RIP0010:memcpy_orig+0xad/0x140 代码e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 310 4c 72 06 4c 8b 4e 08 c RSP0018:ffff888008f57658 EFLAGS00000202 RAX: 0000000000000000 RBX
    ffff888008bd0000 RCX: ffffffff8238e571 RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
     R120000000000000000  : ffff888008f57818 R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 调用跟踪 <TASK> ? __die+0x1f/0x70 ? page_fault_oops+0x1e8/0x500 ? __pfx_is_prefetch.constprop.0+0x10/0x10?
    __pfx_page_fault_oops+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? fixup_exception+0x36/0x460 ?
    _raw_spin_unlock_irqrestore+0x11/0x40 ? exc_page_fault+0x5e/0xc0 ? asm_exc_page_fault+0x26/0x30 xfrm_update_ae_params+0xd1/0x260 ? memcpy_orig+0xad/0x140 ? __pfx__raw_spin_lock_bh+0x10/0x10 xfrm_update_ae_params+0xe7/0x260 xfrm_new_ae+0x298/0x4e0 ? __pfx_xfrm_new_ae+0x10/0x10 ?
    __pfx_xfrm_new_ae+0x10/0x10 xfrm_user_rcv_msg+0x25a/0x410 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ?
    __alloc_skb+0xcf/0x210 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1c/0x70 ?
    __stack_depot_save+0x39/0x4e0 ? __kasan_slab_free+0x10a/0x190 ? kmem_cache_free+0x9c/0x340 ? netlink_recvmsg+0x23c/0x660 ? sock_recvmsg+0xeb/0xf0 ? __sys_recvfrom+0x13c/0x1f0 ?
    __x64_sys_recvfrom+0x71/0x90 ? do_syscall_64+0x3f/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc ? copyout+0x3e/0x50 netlink_rcv_skb+0xd6/0x210 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ?
    __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_sock_has_perm+0x10/0x10 ? mutex_lock+0x8d/0xe0 ?
    __pfx_mutex_lock+0x10/0x10 xfrm_netlink_rcv+0x44/0x50 netlink_unicast+0x36f/0x4c0 ?
    __pfx_netlink_unicast+0x10/0x10 ? netlink_recvmsg+0x500/0x660 netlink_sendmsg+0x3b7/0x700 已为此 Null-ptr-deref 缺陷 分配 CVE-2023-3772。并且此提交在 xfrm_update_ae_params 中添加了其他空检查以修复 NPD。 (CVE-2023-53147)

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

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

  - 已修复 Linux 内核中的下列漏洞：perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox() pci_get_device() will increase the reference count for the returned 'dev'. We need to call pci_dev_put() to decrease the reference count. Since 'dev' is only used in pci_read_config_dword(), let's add pci_dev_put() right after it. (CVE-2022-50318)

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired ratio doesn't match the current ratio, not if the ratio L1 is using for L2 diverges from the default.
    Functionally, the end result is the same as KVM will run L2 with L1's multiplier if L2's multiplier is the default, i.e. checking that L1's multiplier is loaded is equivalent to checking if L2 has a non-default multiplier. However, the assertion that TSC scaling is exposed to L1 is flawed, as userspace can trigger the WARN at will by writing the MSR and then updating guest CPUID to hide the feature (modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking KVM's state_test selftest to do vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR); after restoring state in a new VM+vCPU yields an endless supply of: ------------[ cut here ]------------ WARNING: CPU: 10 PID:
    206939 at arch/x86/kvm/svm/nested.c:1105 nested_svm_vmexit+0x6af/0x720 [kvm_amd] Call Trace:
    nested_svm_exit_handled+0x102/0x1f0 [kvm_amd] svm_handle_exit+0xb9/0x180 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] ? trace_hardirqs_off+0x4d/0xa0 __se_sys_ioctl+0x7a/0xc0 __x64_sys_ioctl+0x21/0x30 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Unlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check into the if-statement is wrong as KVM needs to ensure L1's multiplier is loaded in the above scenario. Alternatively, the WARN_ON() could simply be deleted, but that would make KVM's behavior even more subtle, e.g. it's not immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when checking only tsc_ratio_msr. (CVE-2023-53208)

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

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

  - md/raid10刷新写入时防止软锁定 目前对 raid1/raid10 插入的 bio 没有限制。刷新写入时raid1 有 cond_resched()而 raid10 则没有太多写入可导致软锁定。可通过对具有 ramdisks 的 raid10 的回写测试轻松触发后续软锁定
    watchdog缺陷软锁定 - CPU#10 卡住 27 秒[md0_raid10:1293] 调用跟踪 <TASK> call_rcu+0x16/0x20 put_object+0x41/0x80 __delete_object+0x50/0x90 delete_object_full+0x2b/0x40 kmemleak_free+0x46/0xa0 slab_free_freelist_hook.constprop.0+0xpooled/0x1a0 mem_cached0m03x_free+mem_cached0m03x_free +0x1f/0x30 mempool_free+0x3a/0x100 bio_free+0x59/0x80 bio_put+0xcf/0x2c0 free_r10bio+0xbf/0xf0 raid_end_bio_io+0x78/0xb0 one_write_done+0x8a/0xa0 raid10_end_write_request+0x1b4/0x430 bio_endio+0x175/0x320 brd_submit_bio+0x3b9/0x9b7 [ brd] __submit_bio+0x69/0xe0 submit_bio_noacct_nocheck+0x1e6/0x5a0 submit_bio_noacct+0x38c/0x7e0 flush_pending_writes+0xf0/0x240 raid10d+0xac/0x1ed0 通过像 raid1 一样向 raid10 添加 cond_resched() 来修复 问题。请注意无限插入的 bio 仍需要优化例如在大量脏页回写的情况下这将占用大量内存io 会在插入中花费很长时间因此 io 延迟很差。
    (CVE-2023-53151)

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

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

  - usbdwc3针对设备端点命令超时删除 WARN_ON 此提交解决了一个罕见的端点命令超时此问题在启用“panic_on_warn”时由于警告而导致内核错误以及在禁用“panic_on_warn”时打印不必要的调用跟踪。在软件控制的快速连接/断开连接测试案例中会出现此问题。以下是我们观察到的一个此类端点命令超时1.
    连接 ======= ->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup
    ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data
    ->dwc3_send_gadget_ep_cmd 2. 断开连接 ========== ->dwc3_thread_interrupt
    ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data
    ->dwc3_send_gadget_ep_cmd 在问题场景中在 Exynos 平台中我们发现之前连接的控制权传输尚未完成尚未发送结束传输命令作为断开序列的一部分以及处理 USB_ENDPOINT_HALT 功能请求超时。这可能是预期的情况因为控制器正在处理作为之前连接的一部分发送的 EP 命令。可能最好在发送设备端点命令的所有位置中删除 WARN_ON以避免由于 warn 导致的不必要的内核错误。 (CVE-2025-39801)

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

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

  - ipc修复 init_mqueue_fs() 中的 setup_mq_sysctls() 失败时mqueue_inode_cachep 不会释放。为了修复此问题已对发布路径重新排序。
    (CVE-2022-50284)

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

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

  - scsiufscore从 ufshcd_uic_cmd_compl() 删除 WARN_ON_ONCE() 调用处理 UIC 命令时UIC 完成中断可能被禁用。重新启用 UIC 完成中断时会触发 UIC 中断并命中 WARN_ON_ONCE(!cmd) 语句。因此此修补程序删除了此内核警告。 (CVE-2025-39803)

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

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

  - vxlan修复 nexthop 哈希大小 nexthop 代码预期为 31 位哈希例如 fib_multipath_hash() 和 rt6_multipath_hash() 返回的哈希。传递由 skb_get_hash() 返回的 32 位哈希可导致发生与设置了 MSB 时“int hash”为负数有关的问题。如果是哈希阈值 nexthop 组nexthop_select_path_hthr() 将不成比例地选择第一个 nexthop 组条目。对于可恢复的 nexthop 群组nexthop_select_path_res() 可能在 nh_buckets[]中执行越界访问例如导致以下错误的 hash = -912054133 num_nh_buckets = 2 bucket_index = 65535 addressffffc900025910c8 PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 856 Comm: kworker/4:3 未受感染 6.5.0-rc2+ #34 硬件名称: QEMU Standard PC ( i440FX + PIIX，1996，BIOS 1.16.2-debian-1.16.2-1 04/01/2014 工作队列ipv6_addrconf addrconf_dad_work RIP
    0010:nexthop_select_path+0x197/0xbf0 代码 c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d e8 13 13 13 19 19 0010 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85 RSP0018:ffff88810c36f260 EFLAGS00010246 RAX: 0000000000000000 RBX
    00000000002000c0 RCX: ffffffffaf02dd77 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8 RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219 R10: ffffc900025910cf R11:
     R1231392d2068736168  : 00000000002000c0 R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900 FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900025910c8 CR3: 0000000129d00000 CR40000000000750ee0 PKRU55555554 调用跟踪 <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ?
    __pfx_is_prefetch.constprop.0+0x10/0x10? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 nexthop_select_path+0x197/0xbf0 nexthop_select_path+0x197/0xbf0 lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10
    __pfx___lock_acquire+0x10/0x10 ? __pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350
    __dev_queue_xmit+0x513/0x1e20 ? __pfx___dev_queue_xmit+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ?
    __pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ?
    __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ?
    __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ?
    __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 __kthread_arkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ---truncated--- (CVE-2023-53192)

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

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

  - xsk检查 Tx 路径中较早的 IFF_UP 可通过 sendmsg() 或 poll() syscall 触发 Xsk Tx。
    这两个路径共享对通用函数 xsk_xmit() 的调用该函数内包含两个健全性检查。显示两个路径的伪代码示例__xsk_sendmsg() : xsk_poll() if (unlikely(!xsk_is_bound(xs))) if (unlikely(!xsk_is_bound(xs))) return -ENXIO;返回掩码if (unlikely(need_wait)) (...) 返回
    -EOPNOTSUPP xsk_xmit() 标记 napi id (...) xsk_xmit() xsk_xmit()if (unlikely(!(xs->dev->flags & IFF_UP))) return -ENETDOWN; if (unlikely(!xs->tx)) return -ENOBUFS如上所见在 sendmsg() 中可在未启动的界面上标记 napi id这将造成空指针取消引用 [31757.505631] BUG内核空指针取消引用地址0000000000000018 [31757.512710] # PF内核模式中的主管读取访问 [31757.517936] #PF: error_code(0x0000) - not-present 页面 [31757.523149] PGD 0 P4D 0 [31757.525726] Oops0000 [#1] PREEMPT SMP NOPTI [31757.530154] CPU26 PID
    95641 Commxdpsock 未受感染 6.2.0-rc5+ #40 [31757.536871] 硬件名称Intel Corporation S2600WFT/S2600WFT、BIOS SE5C620.86B.02.01.0008.031920191559 2019 年 3 月 19 日 [31757.547457] RIP
    0010:xsk_sendmsg+0xde/0x180 [31757.551799] Code00 75 a2 48 8b 00 a8 04 75 9b 84 d2 74 69 8b 85 14 01 00 00 85 c0 75 1b 48 8b 85 28 03 00 00 40 9 8b 0 0 0 00 48 8b 40 20 <8b> 40 18 89 85 14 01 00 00 8b bd 14 01 00 00 81 ff 00 01 00 00 0f [31757.570840] RSP: 0018:ffffc90034f27dc0 EFLAGS: 00010246 [31757.576143] RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000 [31757.583389] RDX: 0000000000000001 RSI: ffffc90034f27e18 RDI: ffff88984cf3c100 [31757.590631] RBP: ffff88984714a800 R08: ffff88984714a800 R09: 0000000000000000 [31757.597877] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000fffffffa [31757.605123] R130000000000000000 R140000000000000003 R150000000000000000 [31757.612364] FS:
    00007fb4c5931180(0000) GS:ffff88afdfa00000(0000) knlGS:0000000000000000 [31757.620571] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [31757.626406] CR2: 0000000000000018 CR3: 000000184b41c003 CR4:
    00000000007706e0 [31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [31757.640894] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [31757.648139] PKRU:
    55555554 [31757.650894] 调用跟踪[31757.653385] <TASK> [31757.655524] sock_sendmsg+0x8f/0xa0 [31757.659077] ? sockfd_lookup_light+0x12/0x70 [31757.663416] __sys_sendto+0xfc/0x170 [31757.667051] ? do_sched_setscheduler+0xdb/0x1b0 [31757.671658] __x64_sys_sendto+0x20/0x30 [31757.675557] do_syscall_64+0x38/0x90 [31757.679197] entry_SYSCALL_64_after_hwframe+0x72/0xdc [31757.687969] 代码8e f6 ff 44 8b 4c 24 8b 2c 44 8b 4c 24 8b 2c 24 20 41 89 c4 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 3a 44 89 e7 48 89 08 e2 b8 f6 ff 48 [31757.707007] RSP
    002b:00007ffd49c73c70 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [31757.714694] RAX: ffffffffffffffda RBX: 000055a996565380 RCX: 00007fb4c5727c16 [31757.721939] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 [31757.729184] RBP: 0000000000000040 R08: 0000000000000000 R09: 0000000000000000 [31757.736429] R100000000000000040 R110000000000000293 R120000000000000000 [31757.743673] R13
    0000000000000000 R140000000000000000 R15: 0000000000000000 [31757.754940] </TASK> 要修复此问题让我们将 xsk_xmit 设为将负责通用 Tx的函数、对 RCU 进行相应处理并执行健全性检查和 xs->zc 处理。对 __xsk_sendmsg() 和 xsk_poll() 进行健全性检查。
    (CVE-2023-53240)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/amdgpu: drop redundant sched job cleanup when cs is aborted Once command submission failed due to userptr invalidation in amdgpu_cs_submit, legacy code will perform cleanup of scheduler job. However, it's not needed at all, as former commit has integrated job cleanup stuff into amdgpu_job_free. Otherwise, because of double free, a NULL pointer dereference will occur in such scenario. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457(CVE-2023-53228)

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

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

  - chardev修复 cdev_device_add() 中的错误处理 在执行错误注入测试时我得到以下报告------------[在此切换]------------ kobject“(null)”(0000000039956980) 未初始化但正在调用 kobject_put()。WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0 CPU: 3 PID: 6306 Comm
    283 TaintedGW 6.1.0-rc2-00005-g307c1086d7c9 #1253 Hardware nameQEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP0010:kobject_put+0x23d/ 0x4e0 调用跟踪 <TASK> cdev_device_add+0x15e/0x1b0 __iio_device_register+0x13b4/0x1af0 [industrialio]
    __devm_iio_device_register+0x22/0x90 [industrialio] max517_probe+0x3d8/0x6b4 [max517] i2c_device_probe+0xa81/0xc00 当 device_add() 注入故障并返回错误时如果未设置 dev->devt则不调用 cdev_add()而 cdev_del ) 不是必需的。通过检查错误路径中的 dev->devt 来修复此问题。
    (CVE-2022-50282)

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

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

  - VMCI在调用 get_user_pages_fast() 后检查 context->notify_page 以避免 GPF 对 vmci_host_setup_notify() 中的 get_user_pages_fast() 的调用可返回 NULL context->notify_page 从而造成 GPF。避免 GPF 检查是否 context->notify_page == NULL如果存在则返回错误。一般性保护错误可能是非规范地址 0xe0009d10000000600000 [#1] PREEMPT SMP KASAN NOPTI KASAN可能 wild-memory-access in range [0x0005088000000300- 0x0005088000000307] CPU: 2 PID: 26180 Comm: repro_310241480 -rc4 #1 硬件名称Red Hat KVMBIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP
    0010:vmci_ctx_check_signal_notify+0x91/0xe0 调用跟踪 <TASK> vmci_host_unlocked_ioctl+0x362/0x1f40
    __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2023-53259)

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

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

  - 已修复 Linux 内核中的下列漏洞：md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid() r5l_flush_stripe_to_raid() will check if the list 'flushing_ios' is empty, and then submit 'flush_bio', however, r5l_log_flush_endio() is clearing the list first and then clear the bio, which will cause null-ptr-deref: T1: submit flush io raid5d handle_active_stripes r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init submit_bio // io1 T2: io1 is done r5l_log_flush_endio list_splice_tail_init // clear the list T3: submit new flush io ...
    r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init bio_uninit // clear bio->bi_blkg submit_bio // null-ptr-deref Fix this problem by clearing bio before clearing the list in r5l_log_flush_endio(). (CVE-2023-53210)

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

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

  - raw修复 raw_get_next() 中的空取消引用。Dae R. Jeong 报告了 raw_get_next() 中的一个空取消引用 [0]。repro 似乎正在并行运行这些序列因此一个线程在另一个 netns 中释放的套接字上进行迭代。 unshare(0x40060200) r0 = syz_open_procfs(0x0, &(0x7f0000002080)='net/raw\x00') 套接字$inet_icmp_raw(0x2、0x3、0x1) pread64(r0, &(0x7f0000000000)=/10、0xa、0x10000000007f) 之后提交 0daf07e52709raw将原始套接字转换为 RCU时我们使用 RCU 和 hlist_nulls_for_each_entry() 迭代 SOCK_RAW 套接字。但是我们应该对慢速路径使用旋转锁以避免空指针取消引用。此外SOCK_RAW 不使用 SLAB_TYPESAFE_BY_RCU并且宽限期的迭代期间不会重用 slab 对象。实际上无锁读取程序不会使用 get_nulls_value() 检查 NULL 标记。因此SOCK_RAW 应使用 hlist 而不是 hlist_nulls。我们不通过 sk_nulls_for_each_rcu() 添加不必要的屏障，而是将 hlist_nulls 转换为 hlist，对于快速路径使用 sk_for_each_rcu()，对于 /proc/net/raw 使用 sk_for_each() 和旋转锁。 [0]一般保护错误可能针对非规范地址 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN范围 [0x0000000000000028-0x000000000000002f] CPU: 2 PID: 20952 Comm: syz-executor。 0 未受感染 6.2.0-g048ec869bafd-dirty #7 硬件名称QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010 :read_pnet include/net/net_namespace.h:383 [inline] RIP: 0010:sock_net include/net/sock.h:649 [inline] RIP
    0010:raw_get_next net/ipv4/raw.c:974 [inline] RIP: 0010:raw_get_idx net/ipv4/raw.c:986 [inline] RIP
    0010:raw_seq_start+0x431/0x800 net/ipv4/raw.c:995 代码 ef e8 33 3d 94 f7 49 8b 6d 00 4c 89 ef e8 b7 65 5f f7 49 89 ed 49 83 c5 98 0f 84 9a 00 00 00 48 83 c5 c8 48 89 e8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 ef e8 00 3d 94 f7 4c 8b 7d 00 48 89 ef RSP0018:ffffc9001154f9b0 EFLAGS: 000100000000054f9b0 EFLAGS: 000X000006RB
    1ffff1100302c8fd RCX: 0000000000000000 RDX: 0000000000000028 RSI: ffffc9001154f988 RDI: ffffc9000f77a338 RBP: 0000000000000029 R08: ffffffff8a50ffb4 R09: fffffbfff24b6bd9 R10: fffffbfff24b6bd9 R11:
     R120000000000000000  : ffff88801db73b78 R13: fffffffffffffff9 R14: dffffc0000000000 R15: 0000000000000030 FS: 00007f843ae8e700(0000) GS:ffff888063700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055bb9614b35f CR3: 000000003c672000 CR4: 00000000003506e0 DR0
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> seq_read_iter+0x4c6/0x10f0 fs/seq_file.c:225 seq_read+0x224/0x320 fs/seq_file.c:162 pde_read fs/proc/ inode.c:316 [内联] proc_reg_read+0x23f/0x330 fs/proc/inode.c:328 vfs_read+0x31e/0xd30 fs/read_write.c:468 ksys_pread64 fs/read_write.c:665 [内联] __do_sys_pread64 fs/read_write。 c:675 [内联] __se_sys_pread64 fs/read_write.c:672 [内联] __x64_sys_pread64+0x1e9/0x280 fs/read_write.c:672 do_syscall_x64 arch/x86/entry/common.c:51 [内联] do_syscall_64+0x4e/0xa0 arch /x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP0033:0x478d29 代码 f7 d8 64 89 02 b8 ff ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d48 89 896 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 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f843ae8dbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000011 RAX: ffffffffffffffda RBX: 0000000 000791408 RCX
    0000000000478d29 RDX: 000000000000000a RSI: 0000000020000000 RDI: 0000000000000003 RBP: 00000000f477909a R08: 0000000000000000 R09: 0000000000000000 R10: 000010000000007f R11: 0000000000000246 R12:
    0000000000791740 R130000000000791414 R140000000000791408 R1500007ffc2eb48a50 </TASK> 中链接的模块---[ 结束跟踪 0000000000000000 ]--- RIP: 0010 ---truncated--- (CVE-2023-53198)

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

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

  - tracing修复从合成事件读取字符串 以下命令导致崩溃# cd /sys/kernel/tracing # echo 's:open char file[]' > dynamic_events # echo 'hist:keys=common_pid:file=filename:onchange ($file).trace(open,$file)' >events/syscalls/sys_enter_openat/trigger' # echo 1 >events/synthetic/open/enable BOOM! 问题在于合成事件字段 char file[] 会将提供的值作为字符串读取而不会进行任何内存检查以确保地址有效。上面的示例将传入用户空间地址sythetic 事件代码将愉快地对其调用 strlen()然后调用 strscpy()其中任何一个都会在访问用户空间地址时导致 oops。使用来自 trace_kprobe 和 trace_eprobe 的可安全读取字符串的辅助函数当地址来自用户空间且映射了内存时实际会成功。现在上述内容可以显示packagekitd-1721 [000] ...2. 104.597170open
    file=/usr/lib/rpm/fileattrs/cmake.attr in:imjournal-978 [006] ...2. 104.599642open
    file=/var/lib/rsyslog/imjournal.state.tmp packagekitd-1721 [000] ...2. 104.626308open
    file=/usr/lib/rpm/fileattrs/debuginfo.attrCVE-2022-50255

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

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

  - watchdog修复 watchdog_cdev_register 中的 kmemleak kmemleak 报告 watchdog_dev_register 中的内存泄漏如下未引用的对象 0xffff888116233000(大小 2048)comm modprobe, pid 28147, jiffies 4353426116(age 61.741s) 十六进制转储前 32 字节80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff ....0#....08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#... ............回溯
    [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<000000006a389304>] kmalloc_trace+0x21/0x110 [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog] [<0000000053c9f248>]
    __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133 /0x70f0 ...
    未引用的对象 0xffff888105b9fa80 (大小 16)comm modprobe, pid 28147, jiffies 4353426116 (age 61.741s) 十六进制转储前 16 字节77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1.... ...
    backtrace[<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<00000000486ab89b>]
    __kmalloc_node_track_caller+0x44/0x1b0 [<000000005a39aab0>] kvasprintf+0xb5/0x140 [<0000000024806f85>] kvasprintf_const+0x55/0x180 [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150 [<00000000a92e820b>] dev_set_name+0xab/0xe0 [<00000000cec812c6>] watchdog_dev_register+0x285 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... 原因是在 cdev_device_add 失败且 wdd->id != 0 时不会调用 put_device。 watchdog_cdev_register wd_data = kzalloc [1] err = dev_set_name [2] .. err = cdev_device_add if (err) { if (wdd->id == 0) { // wdd->id != 0 .. } return err; // 将泄漏 [1]、[2] 要修复此问题请在所有 wdd->id 情况中调用 put_device。 (CVE-2023-53234)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/vkms: Fix memory leak in vkms_init() A memory leak was reported after the vkms module install failed. unreferenced object 0xffff88810bc28520 (size 16): comm modprobe, pid 9662, jiffies 4298009455 (age 42.590s) hex dump (first 16 bytes): 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............ backtrace:
    [<00000000e7561ff8>] kmalloc_trace+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0 [<000000001505ee87>] do_init_module+0x1a4/0x680 [<00000000958079ad>] load_module+0x6249/0x7110 [<00000000117e4696>] __do_sys_finit_module+0x140/0x200 [<00000000f74b12d2>] do_syscall_64+0x35/0x80 [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that the vkms_init() returns without checking the return value of vkms_create(), and if the vkms_create() failed, the config allocated at the beginning of vkms_init() is leaked. vkms_init() config = kmalloc(...) # config allocated ... return vkms_create() # vkms_create failed and config is leaked Fix this problem by checking return value of vkms_create() and free the config if error happened. (CVE-2022-50269)

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

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

  - 已修复 Linux 内核中的下列漏洞：lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts Restore the SIMD usability check that was removed by commit a59e5468a921 (crypto: arm64/poly1305 - Add block-only interface). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. (CVE-2025-39804)

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: s390/diag: fix racy access of physical cpu number in diag 9c handler We do check for target CPU == -1, but this might change at the time we are going to use it. Hold the physical target CPU in a local variable to avoid out-of-bound accesses to the cpu arrays. (CVE-2023-53205)

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

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

  - 已修复 Linux 内核中的下列漏洞：bpf, sockmap: fix race in sock_map_free() sock_map_free() calls release_sock(sk) without owning a reference on the socket. This can cause use-after-free as syzbot found [1] Jakub Sitnicki already took care of a similar issue in sock_hash_free() in commit 75e68e5bf2c7 (bpf, sockhash: Synchronize delete from bucket list on map free) [1] refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31 Modules linked in: CPU: 0 PID: 3785 Comm:
    kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: events_unbound bpf_map_free_deferred RIP:
    0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31 Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246 RAX:
    eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0 RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000 RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5 R10:
    fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004 R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] __sock_put include/net/sock.h:779 [inline] tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092 release_sock+0xaf/0x1c0 net/core/sock.c:3468 sock_map_free+0x219/0x2c0 net/core/sock_map.c:356 process_one_work+0x81c/0xd10 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> (CVE-2022-50259)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/bridge: megachips: Fix a null pointer dereference bug When removing the module we will get the following warning: [ 31.911505] i2c-core:
    driver [stdp2690-ge-b850v3-fw] unregistered [ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI [ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130 [31.921825] Call Trace: [ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw] [ 31.923139] i2c_device_remove+0x181/0x1f0 The two bridges (stdp2690, stdp4028) do not probe at the same time, so the driver does not call ge_b850v3_resgiter() when probing, causing the driver to try to remove the object that has not been initialized. Fix this by checking whether both the bridges are probed. (CVE-2022-50317)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: mt76: mt7996: rely on mt76_connac2_mac_tx_rate_val In order to fix a possible NULL pointer dereference in mt7996_mac_write_txwi() of vif pointer, export mt76_connac2_mac_tx_rate_val utility routine and reuse it in mt7996 driver. (CVE-2023-53203)

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

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

  - wifibrcmfmac修复 brcmf_c_preinit_dcmds() 中可能发生的堆栈越界问题 此修补程序修复了 brcmfmac 中的堆栈越界读取问题其将非 null 结尾的“buf”作为 的参数传递时会发生brcmf_c_preinit_dcmds() 中的 strsep()。此缓冲区由 brcmf_fil_iovar_data_get() 中的 memcpy() 填入固件版本字符串。修补程序可确保 buf 以 null 结尾。由 syzkaller 的修改版本发现。[ 47.569679][ T1897] brcmfmac：brcmf_fw_alloc_request：使用 brcm/brcmfmac43236b 作为芯片BCM43236/3 [ 47.582839][ T1897] brcmfmac：brcmf_c_process_clm_blob：没有可用的 clm_blob（err=-2），设备可用的通道可能有限 [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG：KASAN：strsep+0x1b2/0x1f0 中的堆栈越界[ 47.603447][ T1897] 任务 kworker 在地址 ffffc90001f6f000 处读取大小为 1 的数据/0:2/1897  [ 47.604336][ T1897] [ 47.604621][ T1897] CPU：0 PID：1897 通信：kworker/0:2 污染：G O 5.14.0+ #131 [ 47.605617][ T1897] 硬件名称：QEMU 标准 PC（i440FX + PIIX, 1996），BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014  [ 47.606907][ T1897] 工作队列：usb_hub_wq hub_event [ 47.607453][ T1897] 调用跟踪：[ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897]
    __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897]? bus_rescan_devices+0x30/0x30 [47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897]? usb_suspend+0x590/0x590 [ 47.631397][ T1897] real_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [47.633002][ ---truncated--- (CVE-2022-50258)

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

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

  - wifimac80211修复针对未上传的 sta 的无效 drv_sta_pre_rcu_remove 调用避免未初始化的驱动程序私有数据结构造成的潜在数据损坏问题。 (CVE-2023-53229)

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

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

  - cifs修复无 CONFIG_CIFS_DFS_UPCALL 的 DFS 遍历 oops 在禁用 CONFIG_CIFS_DFS_UPCALL 的情况下进行编译cifs_dfs_d_automount 为 NULL。用于将 CIFS_FATTR_DFS_REFERRAL 属性映射到 S_AUTOMOUNT 和相应 dentry 标志的 cifs.ko 逻辑不论 CONFIG_CIFS_DFS_UPCALL而保留导致遍历 DFS 参照链接时 VFS follow_automount() 中发生空指针取消引用缺陷缺陷内核空指针取消引用地址: 00000000000000000 .。 。调用跟踪 <TASK> __traverse_mounts+0xb5/0x220 ? cifs_revalidate_mapping+0x65/0xc0 [cifs] step_into+0x195/0x610 ? lookup_fast+0xe2/0xf0 path_lookupat+0x64/0x140 filename_lookup+0xc2/0x140 ? __create_object+0x299/0x380 ? kmem_cache_alloc+0x119/0x220 ? user_path_at_empty+0x31/0x50 user_path_at_empty+0x31/0x50
    __x64_sys_chdir+0x2a/0xd0 ? exit_to_user_mode_prepare+0xca/0x100 do_syscall_64+0x42/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc 此修复在 CONFIG_CIFS_DFS_UPCALL 禁用时添加内联 cifs_dfs_d_automount() {return -EREMOTE} 处理程序。替代方法是在没有 CONFIG_CIFS_DFS_UPCALL 的情况下避免标记 S_AUTOMOUNT 等。选择此方法的原因是此方法可提供对错误路径的更多控制。 (CVE-2023-53246)

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

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

  - NFSD修复执行服务器间复制时源服务器上的释放后使用。当 laundromat 在服务器间复制完成后尝试释放 s2s_cp_stateids 列表上已过期的 cpntf_state 条目时会发生释放后使用。用于插入过期复制状态的 sc_cp_list 已被释放。COPY 完成时Linux 客户端通常会向源服务器发送 LOCKU(lock_state x)、FREE_STATEID(lock_state x) 和 CLOSE(open_state y)。在释放锁定状态的 stid 之前来自 nfsd4_free_stateid 的 nfs4_put_stid 调用会从 s2s_cp_stateids 列表中清除复制状态。但是，有时 CLOSE 会在 FREE_STATEID 请求之前发送。发生这种情况时从 nfsd4_close 的 nfsd4_close_open_stateid 调用会释放其 st_locks 列表上的所有锁定状态而不清除 sc_cp_list 列表上的复制状态。当 FREE_STATEID 到达时服务器会返回 BAD_STATEID因为锁定状态已释放。这会导致当 laundromat 尝试释放过期的 cpntf_state 时发生释放后使用错误。此修补程序将调用添加到 nfsd4_close_open_stateid 中的 nfs4_free_cpntf_statelist以便在调用 free_ol_stateid_reaplist 之前清理复制状态从而在 reaplist 上释放锁定状态的 stid。 (CVE-2022-50241)

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

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

  - drm/amd/display修复可能包含大型 vblank 的显示的下溢 [原因] 当使用包含大型 vblank 区域和低刷新率的显示器时观察到下溢 [如何] 简化 vblank_nom 的计算将 VBlankNomDefaultUS 的值增加至 800us (CVE-2023-53258)

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

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

  - 已修复 Linux 内核中的下列漏洞：ext4: Fix function prototype mismatch for ext4_feat_ktype With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. ext4_feat_ktype was setting the release handler to kfree, which doesn't have a matching function prototype. Add a simple wrapper with the correct prototype. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches. Note that this code is only reached when ext4 is a loadable module and it is being unloaded: CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698) ... RIP:
    0010:kobject_put+0xbb/0x1b0 ... Call Trace: <TASK> ext4_exit_sysfs+0x14/0x60 [ext4] cleanup_module+0x67/0xedb [ext4] (CVE-2023-53224)

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

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

  - 已修复 Linux 内核中的下列漏洞：md: Replace snprintf with scnprintf Current code produces a warning as shown below when total characters in the constituent block device names plus the slashes exceeds 200. snprintf() returns the number of characters generated from the given input, which could cause the expression 200 len to wrap around to a large positive number. Fix this by using scnprintf() instead, which returns the actual number of characters written into the buffer. [ 1513.267938]
    ------------[ cut here ]------------ [ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510 [ 1513.267944] Modules linked in: <snip> [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu [ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510 <-snip-> [ 1513.267982] Call Trace: [ 1513.267986] snprintf+0x45/0x70 [ 1513.267990] ? disk_name+0x71/0xa0 [ 1513.267993] dump_zones+0x114/0x240 [raid0] [1513.267996] ? _cond_resched+0x19/0x40 [ 1513.267998] raid0_run+0x19e/0x270 [raid0] [ 1513.268000] md_run+0x5e0/0xc50 [ 1513.268003] ? security_capable+0x3f/0x60 [ 1513.268005] do_md_run+0x19/0x110 [1513.268006] md_ioctl+0x195e/0x1f90 [ 1513.268007] blkdev_ioctl+0x91f/0x9f0 [ 1513.268010] block_ioctl+0x3d/0x50 [ 1513.268012] do_vfs_ioctl+0xa9/0x640 [ 1513.268014] ? __fput+0x162/0x260 [1513.268016] ksys_ioctl+0x75/0x80 [ 1513.268017] __x64_sys_ioctl+0x1a/0x20 [ 1513.268019] do_syscall_64+0x5e/0x200 [ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9 (CVE-2022-50299)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini The gmc.ecc_irq is enabled by firmware per IFWI setting, and the host driver is not privileged to enable/disable the interrupt. So, it is meaningless to use the amdgpu_irq_put function in gmc_v10_0_hw_fini, which also leads to the call trace. [ 82.340264] Call Trace: [ 82.340265] <TASK> [82.340269] gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu] [ 82.340447] gmc_v10_0_suspend+0xe/0x20 [amdgpu] [82.340623] amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu] [ 82.340789] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu] [ 82.340955] amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu] [ 82.341122] amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu] [ 82.341359] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu] [ 82.341529] process_one_work+0x21d/0x3f0 [ 82.341535] worker_thread+0x1fa/0x3c0 [ 82.341538] ? process_one_work+0x3f0/0x3f0 [ 82.341540] kthread+0xff/0x130 [82.341544] ? kthread_complete_and_exit+0x20/0x20 [ 82.341547] ret_from_fork+0x22/0x30 (CVE-2023-53193)

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

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

  - 已修复 Linux 内核中的下列漏洞：iommufd: Do not corrupt the pfn list when doing batch carry If batch->end is 0 then setting npfns[0] before computing the new value of pfns will fail to adjust the pfn and result in various page accounting corruptions. It should be ordered after.
    This seems to result in various kinds of page meta-data corruption related failures: WARNING: CPU: 1 PID:
    527 at mm/gup.c:75 try_grab_folio+0x503/0x740 Modules linked in: CPU: 1 PID: 527 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:try_grab_folio+0x503/0x740 Code: e3 01 48 89 de e8 6d c1 dd ff 48 85 db 0f 84 7c fe ff ff e8 4f bf dd ff 49 8d 47 ff 48 89 45 d0 e9 73 fe ff ff e8 3d bf dd ff <0f> 0b 31 db e9 d0 fc ff ff e8 2f bf dd ff 48 8b 5d c8 31 ff 48 89 RSP:
    0018:ffffc90000f37908 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000fffffc02 RCX: ffffffff81504c26 RDX: 0000000000000000 RSI: ffff88800d030000 RDI: 0000000000000002 RBP: ffffc90000f37948 R08:
    000000000003ca24 R09: 0000000000000008 R10: 000000000003ca00 R11: 0000000000000023 R12: ffffea000035d540 R13: 0000000000000001 R14: 0000000000000000 R15: ffffea000035d540 FS: 00007fecbf659740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00000000200011c3 CR3: 000000000ef66006 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: <TASK> internal_get_user_pages_fast+0xd32/0x2200 pin_user_pages_fast+0x65/0x90 pfn_reader_user_pin+0x376/0x390 pfn_reader_next+0x14a/0x7b0 pfn_reader_first+0x140/0x1b0 iopt_area_fill_domain+0x74/0x210 iopt_table_add_domain+0x30e/0x6e0 iommufd_device_selftest_attach+0x7f/0x140 iommufd_test+0x10ff/0x16f0 iommufd_fops_ioctl+0x206/0x330 __x64_sys_ioctl+0x10e/0x160 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc (CVE-2023-53236)

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

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

  - wifiath9k验证预期的 usb_endpoints 是否存在 USB 设备声称是 ATH9K但没有预期的端点时会出现此缺陷。（在这种情况下，在驱动程序预期是一个批量端点的地方，出现了一个中断端点。）内核需要能够在不发生内部错误的情况下处理此类设备。 usb 1-1BOGUS urb xfer管道 3 != 类型 1 警告CPU3 PID500位于 drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c链接在 的 493 模块CPU
    3 PID500 Commkworker/3:2 未受感染5.10.135-syzkaller #0 硬件名称QEMU Standard PC (i440FX + PIIX,1996)、BIOS 1.12.0-1 2014 年 4 月 1 日工作队列事件 request_firmware_work_func RIP
    0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 调用跟踪ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline] ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless /ath/ath9k/hif_usb.c:1019 ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline] ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242 request_firmware_work_func +0x12e/0x240 drivers/base/firmware_loader/main.c:1097 process_one_work+0x9af/0x1600 kernel/workqueue.c:2279 work_thread+0x61d/0x12f0 kernel/workqueue.c:2425 kthread+0x3b4/0x4a0 kernel/kthread.c 313 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299 由 Linux Verification Center (linuxtesting.org) 使用 Syzkaller 发现。 (CVE-2022-50297)

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

ID	名称	严重性
265143	Linux Distros 未修补的漏洞：CVE-2022-50257	medium
265142	Linux Distros 未修补的漏洞：CVE-2025-39829	medium
265141	Linux Distros 未修补的漏洞：CVE-2022-50313	medium
265139	Linux Distros 未修补的漏洞：CVE-2022-50287	medium
265138	Linux Distros 未修补的漏洞：CVE-2022-50268	medium
265137	Linux Distros 未修补的漏洞：CVE-2022-50323	medium
265136	Linux Distros 未修补的漏洞：CVE-2025-59437	low
265135	Linux Distros 未修补的漏洞：CVE-2025-59436	low
265134	Linux Distros 未修补的漏洞：CVE-2023-53179	high
265054	Linux Distros 未修补的漏洞：CVE-2022-50322	medium
265053	Linux Distros 未修补的漏洞：CVE-2023-53165	medium
265052	Linux Distros 未修补的漏洞：CVE-2022-50326	medium
265051	Linux Distros 未修补的漏洞：CVE-2025-39802	high
265050	Linux Distros 未修补的漏洞：CVE-2023-53221	medium
265049	Linux Distros 未修补的漏洞：CVE-2023-53173	medium
265048	Linux Distros 未修补的漏洞：CVE-2022-50250	medium
265047	Linux Distros 未修补的漏洞：CVE-2023-53211	medium
265046	Linux Distros 未修补的漏洞：CVE-2023-53188	medium
265045	Linux Distros 未修补的漏洞：CVE-2023-53147	medium
265044	Linux Distros 未修补的漏洞：CVE-2022-50318	medium
265043	Linux Distros 未修补的漏洞：CVE-2023-53208	medium
265042	Linux Distros 未修补的漏洞：CVE-2023-53151	medium
265041	Linux Distros 未修补的漏洞：CVE-2025-39801	medium
265040	Linux Distros 未修补的漏洞：CVE-2022-50284	medium
265038	Linux Distros 未修补的漏洞：CVE-2025-39803	high
265037	Linux Distros 未修补的漏洞：CVE-2023-53192	high
265036	Linux Distros 未修补的漏洞：CVE-2023-53240	medium
265035	Linux Distros 未修补的漏洞：CVE-2023-53228	medium
265034	Linux Distros 未修补的漏洞：CVE-2022-50282	medium
265033	Linux Distros 未修补的漏洞：CVE-2023-53259	medium
265032	Linux Distros 未修补的漏洞：CVE-2023-53210	medium
265031	Linux Distros 未修补的漏洞：CVE-2023-53198	medium
265030	Linux Distros 未修补的漏洞：CVE-2022-50255	high
265029	Linux Distros 未修补的漏洞：CVE-2023-53234	medium
265028	Linux Distros 未修补的漏洞：CVE-2022-50269	medium
265027	Linux Distros 未修补的漏洞：CVE-2025-39804	high
265026	Linux Distros 未修补的漏洞：CVE-2023-53205	high
265025	Linux Distros 未修补的漏洞：CVE-2022-50259	medium
265024	Linux Distros 未修补的漏洞：CVE-2022-50317	medium
265023	Linux Distros 未修补的漏洞：CVE-2023-53203	medium
265022	Linux Distros 未修补的漏洞：CVE-2022-50258	high
265021	Linux Distros 未修补的漏洞：CVE-2023-53229	medium
265020	Linux Distros 未修补的漏洞：CVE-2023-53246	medium
265019	Linux Distros 未修补的漏洞：CVE-2022-50241	high
265018	Linux Distros 未修补的漏洞：CVE-2023-53258	medium
265017	Linux Distros 未修补的漏洞：CVE-2023-53224	medium
265016	Linux Distros 未修补的漏洞：CVE-2022-50299	medium
265015	Linux Distros 未修补的漏洞：CVE-2023-53193	medium
265014	Linux Distros 未修补的漏洞：CVE-2023-53236	medium
265013	Linux Distros 未修补的漏洞：CVE-2022-50297	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

medium

low

low

high

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

high

medium

medium

medium

medium

medium

medium

high

medium

medium

high

high

medium

medium

medium

high

medium

medium

high

medium

medium

medium

medium

medium

medium