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

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

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

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

  - 解析 DHAV 文件的标头时在偏移计算中存在整数下溢这会导致读取来自分配的缓冲区开始之前的持续时间。如果加载的 DHAV 文件大于 MAX_DURATION_BUFFER_SIZE 字节 (0x100000)例如 0x101000 字节则在 [0] 时大小为 0x101000。在 [1] 中end_buffer_size = 0x100000在 [2] 中end_buffer_pos = 0x1000。然后该循环会向后扫描整个缓冲区以查找 dhav 标签找到时我们将根据从缓冲区读取的 32 位偏移来计算 end_pos。随后会检查 [3]确保 end_pos 是否在已复制到 end_buffer 中的文件部分内但它仅正确处理 end_pos 在文件开始之前或在复制到 end_buffer 中的部分之后的情况而不是end_pos 在文件内但在复制到 end_buffer 中的部分之前的情况。如果提供此类偏移end_pos - end_buffer_pos 可能会下溢导致在开始分配之前发生 [4] 的后续访问。建议升级到版本 8.0 或更高版本。
    (CVE-2025-59729)

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

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

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

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

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

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

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

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

  - ASoC 编解码器sma1307修复 sma1307_setting_loaded() 中的内存损坏 sma1307->set.header_size 是指标头中所含整数的数量有 8 但我们没有分配 8 个整数的空间而是分配 8 个字节。当我们在下一行复制数据时这会导致内存损坏
    memcpy(sma1307->set.header, data, sma1307->set.header_size * sizeof(int));此外由于我们立即复制 ->set.header 中的内存因此无需在分配器中将其归零。改用 devm_kmalloc_array() 分配内存。 (CVE-2025-39935)

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

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

  - mtdlpddr2_nvm修复可能的 null-ptr-deref 当 resource_size(add_range) 调用时如果 platform_get_resource() 返回 NULL它将导致 null-ptr-deref。 (CVE-2022-50503)

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

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

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

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

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

  - stagingks7010ks_wlan_set_encode_ext() 中存在缓冲区溢出 exc->key_len 是来自 user 的 u16 密钥。超过 IW_ENCODING_TOKEN_MAX (64) 可导致内存损坏。
    (CVE-2023-53554)

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

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

  - 解码使用 DWAA 或 DWAB 压缩的 OpenEXR 文件时存在高度和宽度可被 8 整除的隐式假设。如果图像的高度或宽度不可被 8 整除则复制会在 [0] 和 [ 1] 将继续写入直到下一个 8 的倍数。缓冲区 td->uncompressed_data 是根据图像的精确高度和宽度在 decode_block 中分配的因此复制循环中向上舍入的 8 的倍数可能会超过缓冲区界，并且在 [2] 处开始的写入区块会损坏后续的堆内存。建议升级到版本 8.0 或更高版本。 (CVE-2025-59732)

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

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

  - 解码使用 DWAA 或 DWAB 压缩的 OpenEXR 文件时在使用游程长度编码数据计算输出数据时未检查游程长度编码数据的指定原始长度。我们从 [0] 的输入文件读取 rle_raw_size我们会解压缩并解码到 [1] 的 rle_raw_size 大小的缓冲区 td->rle_raw_data然后在 [2] 我们将访问此缓冲区中直到 td-> xsize - 1) * (td->ysize - 1) + rle_raw_size / 2可能超过 rle_raw_size。建议升级到版本 8.0 或更高版本。
    (CVE-2025-59731)

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

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

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

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

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

  - nilfs2修复 nilfs_segctor_thread() 中 struct nilfs_sc_info 的潜在 UAF nilfs_segctor_thread() 的最终实现可与 nilfs_segctor_kill_thread() 争用从而终止该线程从而可能造成 KASAN 检测到的释放后使用缺陷。在 nilfs_segctor_thread() 结束时先向结构 nilfs_sc_info 的 sc_task 成员分配 NULL 以指示线程已完成然后使用结构 nilfs_sc_info 上的等待队列 sc_wait_task 将此情况通知 nilfs_segctor_kill_thread()。然而在此紧接着将空值分配给 sc_task 之后nilfs_segctor_kill_thread() 可能会检测到并返回以继续解除分配从而在线程进行通知之前释放 nilfs_sc_info 结构。这通过使用 struct nilfs_sc_info 的旋转锁 sc_state_lock 保护 sc_task 的空分配及其通知来修复此问题。由于 nilfs_segctor_kill_thread() 会在 sc_state_lock 锁定的情况下进行最终检查查看 sc_task 是否为空因此这可以消除争用。
    (CVE-2023-53608)

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

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

  - 对使用 DWAA 或 DWAB 压缩的 OpenEXR 文件进行解码时存在一个隐式假设所有图像通道都具有相同的像素类型和大小并且如果有四个通道则前四个为 B、G、R 和 A 。通道解析代码可在 decode_header 中找到。会在 decode_block 中根据 xsize、ysize 和计算得到的 current_channel_offset 在 decode_block 中分配缓冲区 td->uncompressed_data。然后函数 dwa_uncompress在 [5] 中假设如果有 4 个通道即 B、G、R 和 A并且在 [6] 和 [7] 中的计算中假设所有通道均为相同类型该类型与主要颜色通道的类型。如果将主颜色通道设置为 4 字节类型并添加 2 字节 EXR_HALF 类型的重复或未知通道则 [7] 中的添加会将指针增加 4 字节 * xsize * nb_channels这将超过分配的缓冲区。建议升级到版本 8.0 或更高版本。 (CVE-2025-59733)

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

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

  - Litestar 是一个异步服务器网关接口 (ASGI) 框架。在版本 2.17.0中通过操纵 X-Forwarded-For 标头可完全绕过速率限制。这使得基于 IP 的速率限制对既定的攻击者无效。Litestar 的 RateLimitMiddleware 使用“cache_key_from_request()”来生成缓存密钥以进行速率限制。存在 X-Forwarded-For 标头时中间件会无条件信任该标头并使用其值作为客户端标识符的一部分。由于客户端可设置任意 X-Forwarded-For 值因此每个不同的伪造 IP 都会创建单独的速率限制存储段。攻击者可以轮换不同的标头值以避免达到任何单个存储段的限制。这会影响以默认设置使用 RateLimitMiddleware 的所有 Litestar 应用程序其中可能包括实现速率限制的大多数应用程序。 2.18.0 版中包含针对 漏洞的修补程序。
    (CVE-2025-59152)

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

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

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

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

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

  - python-socketio 是 Socket.IO 实时客户端和服务器的 Python 实现。在低于 5.14.0 的 python-socketio 版本中存在远程代码执行漏洞，在攻击者此前已获得服务器间用于内部通信的消息队列访问权限的多服务器部署环境中，这个漏洞允许攻击者通过恶意的 pickle 反序列化执行任意 Python 代码。当 Socket.IO 服务器被配置为使用诸如 Redis 之类的消息队列后端来进行服务器间通信时，服务器之间发送的消息是使用 Python 的 pickle 模块进行编码的。当服务器通过消息队列接收到其中一条消息时，它会假定该消息是可信的，并立即对其进行反序列化。漏洞的根源在于使用 Python 的 pickle.loads() 函数对消息进行反序列化。攻击者如果事先获得了对消息队列的访问权限，就可以向 python-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 依赖供应商报告的程序包是否存在进行判断。

ID	名称	严重性
269328	Linux Distros 未修补的漏洞：CVE-2022-50499	medium
269327	Linux Distros 未修补的漏洞：CVE-2025-59729	medium
269326	Linux Distros 未修补的漏洞：CVE-2025-39936	medium
269325	Linux Distros 未修补的漏洞：CVE-2022-50483	medium
269324	Linux Distros 未修补的漏洞：CVE-2025-39935	high
269323	Linux Distros 未修补的漏洞：CVE-2022-50503	medium
269322	Linux Distros 未修补的漏洞：CVE-2023-53533	medium
269321	Linux Distros 未修补的漏洞：CVE-2023-53554	high
269320	Linux Distros 未修补的漏洞：CVE-2025-59732	high
269319	Linux Distros 未修补的漏洞：CVE-2025-59731	medium
269318	Linux Distros 未修补的漏洞：CVE-2023-53551	medium
269317	Linux Distros 未修补的漏洞：CVE-2023-53608	medium
269316	Linux Distros 未修补的漏洞：CVE-2025-59733	high
269315	Linux Distros 未修补的漏洞：CVE-2025-59152	high
269314	Linux Distros 未修补的漏洞：CVE-2023-53583	medium
269313	Linux Distros 未修补的漏洞：CVE-2025-61765	medium
269312	Linux Distros 未修补的漏洞：CVE-2022-50471	high
269311	Linux Distros 未修补的漏洞：CVE-2023-53556	high
269310	Linux Distros 未修补的漏洞：CVE-2022-50474	medium
269309	Linux Distros 未修补的漏洞：CVE-2025-61774	critical
269308	Linux Distros 未修补的漏洞：CVE-2023-53541	high
269307	Linux Distros 未修补的漏洞：CVE-2023-53569	high
269306	Linux Distros 未修补的漏洞：CVE-2023-53542	medium
269305	Linux Distros 未修补的漏洞：CVE-2022-50480	medium
269304	Linux Distros 未修补的漏洞：CVE-2022-50501	medium
269303	Linux Distros 未修补的漏洞：CVE-2022-50478	high
269302	Linux Distros 未修补的漏洞：CVE-2025-59730	medium
269301	Linux Distros 未修补的漏洞：CVE-2025-59734	high
269300	Linux Distros 未修补的漏洞：CVE-2025-61224	medium
269299	Linux Distros 未修补的漏洞：CVE-2023-53573	medium
269298	Linux Distros 未修补的漏洞：CVE-2023-53592	high
269297	Linux Distros 未修补的漏洞：CVE-2025-61766	medium
269296	Linux Distros 未修补的漏洞：CVE-2025-56200	medium
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

检测

Nessus 的 Misc. 系列

medium

medium

medium

medium

high

medium

medium

high

high

medium

medium

medium

high

high

medium

medium

high

high

medium

critical

high

high

medium

medium

medium

high

medium

high

medium

medium

high

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium

medium

medium

high

high

medium

high

high

medium