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

  - 已发现 Mesa v23.0.4 中包含通过函数 dri2GetGlxDrawableFromXDrawableId() 实现的空指针取消引用。如果 X11 服务器在应用程序使用 DRI3 时意外发送 DRI2_BufferSwapComplete 事件，便会触发此漏洞。注意：这一点存在争议，因为不存在可证实该漏洞的场景。(CVE-2023-45913)

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

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

  - 发现 Mesa 23.0.4 的 glXQueryServerString() 中存在缓冲区过度读取漏洞。注意：这是有争议的，因为不存在用户要求攻击者控制服务器不中断操作的常见情况。(CVE-2023-45919)

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

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

  - 发现 Mesa 23.0.4 中的 glx_pbuffer.c 在调用
    __glXGetDrawableAttribute() 时存在分段冲突。注意：这是有争议的，因为不存在用户要求攻击者控制服务器不中断操作的常见情况。(CVE-2023-45922)

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

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

  - 发现在 has_error 状态下，Mesa 23.0.4 的 check_xshm() 中存在空指针取消引用漏洞。
    注意：这一点存在争议，因为不存在可证实该漏洞的场景。
    (CVE-2023-45931)

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

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

  - Evolution 2.8.1 及更早版本在调用 GnuPG 时未正确使用 --status-fd 参数，这会阻止 Evolution 以可视方式区分具有多个组件的 OpenPGP 消息的已签名与未签名部分，进而允许远程攻击者在不被发现的情况下伪造消息内容。(CVE-2007-1266)

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

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

  - 使用大量 VCPU 时，Xen 4.4.x 及更早版本未正确处理读取和写入锁定，这允许本地 x86 客户机用户通过大量读取请求造成拒绝服务（写入遭拒或 NMI 监视程序超时，以及主机崩溃），此漏洞与 CVE-2014-9065 不同。
    (CVE-2014-9066)

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

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

  - x86：具有纯（非 shim）32 位 PV 客户机的推测漏洞 32 位 x86 PV 客户机内核在 1 环中运行。开发 Xen 时，很少使用 i386 架构的这个区域，这就是为什么 Xen 能够使用它来实现半虚拟化，这是 Xen 的全新虚拟化方法。在 AMD64 中，Xen 必须使用不同的实现方法，因此 Xen 不使用 1 环来支持 64 位客户机。鉴于现在侧重使用 64 位系统，并且存在明确的虚拟化硬件支持，因此修复 1 环中的推测问题就不是处理器公司的优先任务。Indirect Branch Restricted Speculation (IBRS) 是一种架构 x86 扩展，可用于对抗推测执行边信道攻击，包括 Spectre v2。已在现有 CPU 的微代码中对其进行更新。有关 Spectre v2 的更多详细信息，请参阅：http://xenbits.xen.org/xsa/advisory-254.html 但是，IBRS 不会通过架构保护 0 环，使其免受从 1 环中习得的预测的影响。有关更多详细信息，请参阅：
    https://software.intel.com/security-software-guidance/deep-dives/deep-dive-indirect-branch-restricted-speculation 其他类型的推测执行攻击的其他缓解措施也可能存在类似情况。这种情况很可能与尚未发现、披露或缓解的推测执行攻击类似。(CVE-2021-28689)

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

检测到 Acclaim Systems USAHERDS 的 Web 界面。

远程 Linux 主机上已安装 Termius。

远程主机上安装的 LibreOffice 版本为低于 24.8.5 或 25.2.1。因此，它受到 cve-2025-1080 公告中提及的一个漏洞影响。

  - LibreOffice 支持 Office URI 方案，以实现 LibreOffice 与 MS SharePoint 服务器的浏览器集成。添加了一个特定于 LibreOffice 的额外方案“vnd.libreoffice.command”。在受影响的 LibreOffice 版本中，使用该方案的浏览器中的链接可以通过嵌入的内部 URL 进行构建，当该 URL 传递给 LibreOffice 时，可以调用带有任意参数的内部宏。此问题影响 LibreOffice：从 24.8 到 < 24.8.5、从 25.2 到 < 25.2.1。(CVE-2025-1080)

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

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

  - 在 Linux 内核中，已解决以下漏洞： PCI：在 TUXEDO Sirius Gen1 中避免将某些根端口置于 D3 提交 9d26d3a8f1b0（PCI：在暂停期间将 PCIe 端口置于 D3）设定了允许所有 PCIe 端口使用的策略 D3。当系统挂起时，如果平台无法对端口进行电源管理，也不会通过 PME 唤醒端口，则会为这些端口设置进入 D3hot 状态的策略。从 OSPM 的角度来说，此策略通常是合理的，但它会导致包含特定旧 BIOS 的 TUXEDO Sirius 16 Gen 1 上的暂停唤醒出现问题。这表现为系统挂起。在受影响的设备 + BIOS 组合上，为有问题的控制器的根端口添加 quirk，以确保这些根端口在暂停时不会进入 D3hot 模式。此修补程序基于 https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.com，但在文档和代码中添加了条件，使其仅应用到具有特定旧 BIOS 的 TUXEDO Sirius 16 Gen 1 并且仅应用受影响的根端口。(CVE-2025-21831)

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

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

  - 在 Linux 内核中，已解决以下漏洞：idpf：将 workqueue 转换为 unbound 当通过“WQ_UNBOUND”创建工作队列时，其工作项目由特殊的工作线程池提供服务，其主机工作线程池未绑定到任何特定 CPU。在默认配置中（即“queue_delayed_work”和好友未指定运行工作项目的 CPU 时），“WQ_UNBOUND”允许在与其排入队列的相同 CPU 节点中的任何 CPU 上执行工作项目。尽管此解决方案可能会牺牲本地性，但它可避免与可能独占安排了工作项目的处理器的 CPU 时间的其他进程争用。这不只是一个理论上的问题：在特定情况下，错误配置的进程占用了 CPU0 的大部分时间，留给 kworker 的只有不到其 CPU 0.5% 的时间。因此，在 CPU0 上使用 kworker 的 IDPF 工作队列出现了较大的完成延迟，导致性能下降、超时并最终导致系统崩溃。* 我还进行了手动测试，以衡量性能改善情况。测试包含尽可能多地消耗 CPU 0 的对抗进程（“./stress --cpu 2”）。此进程在“taskset 01”下运行以将其绑定至 CPU0，启动后其优先级会因“chrt -pQ 9900 10000 ${pid}”和“renice -n -20 ${pid}”改变。然后，通过编辑所有对“queue_delayed_work”、“mod_delayed_work”等的调用，强制 IDPF 驱动程序优先使用 CPU0。 最后，收集工作队列事件的“ktraces”。如果没有当前的修补程序，对抗进程可在“workqueue_queue_work”和“workqueue_execute_start”之间强制任意延迟，在我的测试中延迟高达“30ms”。应用当前修补程序后，工作队列可迁移到同一节点中另一个未加载的 CPU，在其他条件相同的情况下，我发现的最大延迟为“6us”。(CVE-2024-58057)

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

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

  - 在 Linux 内核中，已解决以下漏洞：wifi：rtlwifi：修复探测失败时以相反顺序进行的探测错误路径中的内存泄漏和无效访问。当 init_sw_vars 失败时，不应调用 rtl_deinit_core，尤其是因为它会破坏 rtl_wq 工作队列。并调用 rtl_pci_deinit 和 deinit_sw_vars，否则内存将被泄露。删除了 pci_set_drvdata 调用，因为它已由核心驱动程序代码清理，并且也可能导致内存泄漏。cf。提交 8d450935ae7f（wireless：rtlwifi：删除不必要的 pci_set_drvdata()）和提交 3d86b93064c7（rtlwifi：修复 PCI 探测错误路径孤立的内存）。(CVE-2024-58063)

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

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

  - 在 Linux 内核中，以下漏洞已得到解决：wifi：mac80211：不刷新未上传的 STA 如果 STA 状态预先移至 AUTHORIZED（如在 IBSS 情况中）并且插入失败，则将释放该站点。在这种情况下，驱动程序根本不知道该站的存在，因此尝试刷新是意外之举，并且可能会崩溃。检查之前是否将 sta 上传到了驱动程序，并解决这个问题。
    (CVE-2025-21828)

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

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

  - 在 Linux 内核中，解决了以下漏洞：media：nuvoton：修复 npcm_video_ece_init() 中的一个错误检查。当函数 of_find_device_by_node() 失败时，它返回 NULL 而非错误代码。因此，应修改相应的错误检查逻辑，以检查返回值是否为 NULL 并将错误代码设置为 -ENODEV 返回。(CVE-2024-58082)

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

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

  - 在 Linux 内核中，以下漏洞已得到解决：bpf：取消通过 kworker 为 PREEMPT_RT 运行 bpf_timer 在更新过程中，当覆盖预分配 htab 中的元素时，old_element 的释放受到存储段锁的保护。之所以需要桶锁，是因为在 alloc_htab_elem() 返回后，old_element 已被存放在 htab->extra_elems 中。如果在桶锁解锁后释放 old_element，则存储的元素可能会被并发更新过程重新使用，释放 old_element 的过程将与重新使用 old_element 的过程同时进行。但是，调用 check_and_free_fields() 时可能会获得一个自旋锁，这违反了锁定规则，因为调用者已经持有一个原始自旋锁（桶锁）。当发生这种竞赛时，将报告以下警告： BUG: scheduling while atomic: test_progs/676/0x00000003 test_progs/676 持有 3 个锁：#0：fffffff864b0240 (rcu_read_lock_trace){....}-{0:0}, at：
    bpf_prog_test_run_syscall+0x2c0/0x830 #1: ffff88810e961188 (&htab->lockdep_key){....}-{2:2}，at：
    htab_map_update_elem+0x306/0x1500 #2: ffff8881f4eac1b8 (&base->softirq_expiry_lock){....}-{2:2}，at：
    hrtimer_cancel_wait_running+0xe9/0x1b0 模块在以下位置链接：bpf_testmod(O)。以下位置禁用 Preemption：
    [<ffffffff817837a3>] htab_map_update_elem+0x293/0x1500 CPU: 0 UID: 0 PID: 676 Comm：test_progs 受感染：G ... 6.12.0+ #11 受感染：[W]=WARN，[O]=OOT_MODULE 硬件名称：QEMU 标准 PC (i440FX + PIIX, 1996)...
    调用跟踪：<TASK> dump_stack_lvl+0x57/0x70 dump_stack+0x10/0x20 __schedule_bug+0x120/0x170
    __schedule+0x300c/0x4800 schedule_rtlock+0x37/0x60 rtlock_slowlock_locked+0x6d9/0x54c0 rt_spin_lock+0x168/0x230 hrtimer_cancel_wait_running+0xe9/0x1b0 hrtimer_cancel+0x24/0x30 bpf_timer_delete_work+0x1d/0x40 bpf_timer_cancel_and_free+0x5e/0x80 bpf_obj_free_fields+0x262/0x4a0 check_and_free_fields+0x1d0/0x280 htab_map_update_elem+0x7fc/0x1500 bpf_prog_9f90bc20768e0cb9_overwrite_cb+0x3f/0x43 bpf_prog_ea601c4649694dbd_overwrite_timer+0x5d/0x7e bpf_prog_test_run_syscall+0x322/0x830 __sys_bpf+0x135d/0x3ca0 __x64_sys_bpf+0x75/0xb0 x64_sys_call+0x1b5/0xa10 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...</TASK> 将按 CPU 计算的 extra_elems 的重用和重新填充分成两个独立部分似乎可行：在水桶锁保持不变的情况下重用按 CPU 计算的 extra_elems，并在水桶锁解锁后重新填充 old_element 作为按 CPU 计算的 extra_elems。不过，当映射已满时，它会使同一 CPU 上的并发覆盖程序返回意外的 -E2BIG 错误。因此，补丁通过将取消 bpf_timer 分解为 PREEMPT_RT 的两个步骤，解决了锁的问题：1）使用 hrtimer_try_to_cancel()，并检查其返回值 2）如果定时器正在运行，则通过 kworker 使用 hrtimer_cancel()，再次取消定时器 考虑到当前 hrtimer_cancel() 的实现会在当前定时器运行时尝试获取一个被持有的 softirq_expiry_lock，上述步骤是合理的。但是，它也有缺陷。当计时器运行时，在释放最后一个地图 uref 时会延迟取消计时器。延迟也可以得到解决（例如，将 bpf 定时器的取消分为两部分：一部分在锁定的作用域中，另一部分在未锁定的作用域中），必要时可以稍后修改。要确定正确的固定标签有点困难。原因之一是该问题取决于 v6.12 中启用的 PREEMPT_RT。
    考虑到 softirq_expiry_lock 自 v5.4 版起就已存在，而 bpf_timer 则在 v5.15 版中引入，因此在 fixes 标记中使用了 bpf_timer commit，并添加了额外的 depends-on 标记，以说明对 PREEMPT_RT 的依赖。取决于：启用了 PREEMPT_RT 的 v6.12+ (CVE-2025-21825)

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

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

  - 在 systemd 253 中发现了问题。攻击者可以修改密封的日志文件中过去事件的内容，然后调整文件，使得完整性检查在存在修改的情况下也显示无错误。
    注意：据报告，供应商发送了一条回复，称其中任何一项发现都不是安全漏洞。
    (CVE-2023-31439)

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

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

  - 在 Linux 内核中，已解决以下漏洞：drm/i915：从编码器获取 intel_display 以避免可能的 oopsies 从编码器挂钩中的“encoder”而非“state”获取 intel_display，以避免 intel_sanitize_encoder 的大量 footgun ()，它将 NULL 作为“state”参数传递给编码器 .disable() 和 .post_disable()。TODO：了解如何实际修复 intel_sanitize_encoder()...(CVE-2024-58074)

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

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

  - 在 Linux 内核中，以下漏洞已解决：clk：mmp2：仅在设置 genpd.name 后调用 pm_genpd_init() 在 pm_genpd_init() 内使用 dev_set_name() 设置 genpd 的 struct 设备名称。如果其保持为 NULL，则日后可能会崩溃，例如构建 power 域的 devfs 层次时： 读取时，无法处理虚拟地址 00000000 上的内核空指针取消引用 ... Call trace: strlen from start_creating+0x90/0x138 start_creating from debugfs_create_dir+0x20/0x178 debugfs_create_dir from genpd_debug_add.part.0+0x4c/0x144 genpd_debug_add.part.0 from genpd_debug_init+0x74/0x90 genpd_debug_init from do_one_initcall+0x5c/0x244 do_one_initcall from kernel_init_freeable+ kernel_init+0x1c 的 0x19c/0x1f4 kernel_init_freeable 以及 ret_from_fork+0x14/0x28 Bisecting 的 0x12c kernel_init 会跟踪此崩溃回到提交 899f44531fe6（pmdomain：核心：添加 GENPD_FLAG_DEV_NAME_FW 标记），该提交将 genpd->name 与 dev_name 交换使用 (&genpd->dev ) genpd_debug_add.part() 中的缺陷。(CVE-2024-58081)

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

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

  - 在 Linux 内核中，以下漏洞已得到解决：wifi：iwlwifi：mvm：避免空指针取消引用当迭代 vif 的链接时，我们需要确保指针有效（换句话说，即链接 exists），然后再取消引用。使用同样执行检查的 for_each_vif_active_link。(CVE-2024-58062)

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

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

  - 在 5.1.7 版之前的 Django 5.1、5.0.13 版之前的 Django 5.0 以及 4.2.20 版之前的 Django 4.2 中发现一个问题。当使用超长字符串时，django.utils.text.wrap() 方法和 wordwrap 模板过滤器可能会受到拒绝服务攻击。(CVE-2025-26699)

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

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

  - 在 Linux 内核中，以下漏洞已得到解决： block: don't revert iter for
    -EIOCBQUEUED blkdev_read_iter() 有一些奇怪的检查，例如对结果是否大于或等于零（其中大于等于零更有意义）的位置和计数调整进行门控，以及不检查 的返回值。 blkdev_direct_IO()，在执行 iov_iter_revert() 之前。后者可导致尝试以负值恢复，当该负值作为无符号值传递至 iov_iter_revert() 时，将导致抛出 WARN_ON()，因为 unroll 大于 MAX_RW_COUNT。保持理顺，不要恢复
    -EIOCBQUEUED，这与在其他场景中的执行方式一样。(CVE-2025-21832)

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

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

  - 在 Linux 内核中，解决了以下漏洞：ASoC：soc-pcm：不要在 .prepare 回调提交 1f5664351410 上使用 soc_pcm_ret()（ASoC：较低的版本没有针对... Port 日志严重性）忽略通用 soc_pcm_ret() 中的 -EINVAL 错误消息。它用于众多函数，并忽略
    -EINVAL 过度杀伤。忽略 -EINVAL 的原因是，它只能用于来自用户空间的无效参数，在这种情况下，我们不想记录错误，因为我们不想让用户空间有机会对 syslog/磁盘空间进行拒绝服务攻击。因此，请勿在 .prepare 回调中使用 soc_pcm_ret() 为更好的建议。(CVE-2024-58077)

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

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

  - 解决了 Linux 内核中的以下漏洞： staging： media：max96712：修复删除模块时发生的内核 oops 尝试删除 max96712 模块时会抛出以下内核 oops：
    无法处理位于虚拟地址 00007375746174db 内存的内核分页请求：ESR = 0x0000000096000004 EC = 0x25：DABT（当前 EL），IL = 32 位 SET = 0，FnV = 0 EA = 0，S1PTW = 0 FSC = 0x04：level 0 转换错误 数据中止信息：ISV = 0、ISS = 0x00000004、ISS2 = 0x00000000 CM = 0、WnR = 0、TnD = 0、TagAccess = 0 GCS = 0、Overlay = 0、DirtyBit = 0、Xs = 0 用户 pgtable ：4k 页面，48 位 VA， pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000、p4d=0000000000000000 内部错误：Oops：
    0000000096000004 [#1] PREEMPT SMP Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2 imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse [last unloaded: imx8_isi] CPU: 0 UID: 0 PID ：754 Comm：
    rmmod Tainted：GC 6.12.0-rc6-06364-g327fec852c31 #17 Tainted：[C]=CRAP 硬件名称：NXP i。MX95 19X19 板 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : led_put+0x1c/0x40 lr：
    v4l2_subdev_put_privacy_led+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23:
    ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14:
    0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 :
    8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace: led_put+0x1c/0x40 v4l2_subdev_put_privacy_led+0x48/0x58 v4l2_async_unregister_subdev+0x2c/0x1a4 max96712_remove+0x1c/0x38 [max96712] i2c_device_remove+0x2c/0x9c device_remove+0x4c /0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x4c/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 max96712_i2c_driver_exit+0x18/0x1d0 [max96712] __arm64_sys_delete_module+0x1a4/0x290 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0 +0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]--- 在 v4l2_i2c_subdev_init( ）中会再次发生，会再次调用 i2c_set_cliendata() 并覆盖数据以指向 sd 而不是 priv。因此，在 remove() 中，将错误的指针传递给 v4l2_async_unregister_subdev()，从而导致崩溃。
    (CVE-2024-58054)

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

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

  - Linux 内核中，以下漏洞已得到解决：ipmi：ipmb：添加检查 devm_kasprintf() 返回值 devm_kasprintf() 在失败时可返回空指针，但不会检查此返回值。(CVE-2024-58051)

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

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

  - 在 Linux 内核中，解决了以下漏洞：iommu/vt-d：避免在 WARN_ON_ONCE 之后使用 NULL 存在一个 WARN_ON_ONCE 来捕获 domain_remove_dev_pasid 找不到 `pasid` 时这种不太可能的情况。如果出现这种情况，我们必须避免使用空指针。(CVE-2025-21833)

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

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

  - 在 Linux 内核中，解决了以下漏洞：remoteproc：核心：修复未分配时的 ida_free 调用 在 rproc_alloc() 函数中，发生错误时，put_device(&rproc->dev) 会被调用，导致调用 rproc_type_release () 函数。调用 ida_alloc 之前可发生错误。在 rproc_type_release() 中，条件 (rproc->index >= 0) 为真，因为 rproc->index 已初始化为 0。调用 ida_free() 报告警告：[4.181906] 警告：CPU：1 PID：24 at lib/idr.c:525 ida_free+0x100/0x164 [4.186378] stm32-display-dsi 5a000000.dsi：修复了与 /soc/dsi@5a000000/panel@0 的依存关系周期 [4.188854] ida_free 调用了未分配的 id=0。 [4.198256] mipi-dsi 5a000000.dsi.0：修复了与 /soc/dsi@5a000000 的依存关系周期 [4.203556] 模块链接于：
    panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+) [4.224307] CPU:1 UID: 0 PID: 24 Comm: kworker/u10:0 未感染 6.12.0 #442 [4.231481] 硬件名称：STM32（设备树支持）[4.236627] 工作队列：events_unbound deferred_probe_work_func [4.242504] 调用跟踪：[4.242522] show_stack+0x10/0x14 的 unwind_backtrace [4.250218] dump_stack_lvl+0x50/0x64 的 show_stack [4.255274] __warn+ 的 dump_stack_lvl 0x80/0x12c [4.260134] 来自 warn_slowpath_fmt+0x114/0x188 的 __warn [4.265199] 来自 ida_free+0x100/0x164 的 warn_slowpath_fmt [4.270565] 来自 rproc_type_release+0x38/0x60 [4.275832] 的 rproc_type_release [4.281601] 来自 kobject_put+0xc4/0x294 的 device_release [4.286762] 来自 rproc_alloc.part.0+0x28c 的 kobject_put [4.292430] 来自 devm_rproc_alloc+0x80/0x28c4 的 rproc_alloc.part.0 [4.298393] 来自 stm32_rproc_probe+0xd0/0x844 的 devm_rproc_alloc [stm32_rproc] [4.305575] stm32_rproc_probe [stm32_rproc] 来自 platform_probe+0x5c/0xbc 早前在 rproc_alloc 中调用 ida_alloc 确保已正确设置 rproc->index。(CVE-2024-58056)

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

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

  - 在 Linux 内核中，解决了以下漏洞：drm/amdgpu：修复 atomctrl_get_smc_sclk_range_table 中潜在的空指针取消引用 函数 atomctrl_get_smc_sclk_range_table() 不会检查 smu_atom_get_data_table() 的返回值。如果 smu_atom_get_data_table() 无法检索 SMU_Info 表，它将返回之后取消引用的 NULL。由 Linux Verification Center (linuxtesting.org) 和 SVACE 发现。在实践中，这种情况永远不应发生，因为此代码只会在 polaris 芯片上调用，而 vbios 数据表在这些芯片上始终存在。(CVE-2024-58052)

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

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

  - 在 systemd 253 中发现了问题。攻击者可修改密封的日志文件，进而导致在某些视图中并非显示所有现有和密封的日志消息。请注意：据报告，供应商在回复中否认任何发现都是安全漏洞。(CVE-2023-31437)

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

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

  - 在 Linux 内核中，已解决以下漏洞：clk：qcom：gcc-sm6350：为两个时钟添加缺少的 parent_map 若 clk_rcg2 有父项，其应也已定义 parent_map，否则将发生空指针取消引用当如下调用 clk_set_rate 时：[3.388105] 调用跟踪：
    [3.390664] qcom_find_src_index+0x3c/0x70 (P) [3.395301] qcom_find_src_index+0x1c/0x70 (L) [3.399934]
    _freq_tbl_determine_rate+0x48/0x100 [3.404753] clk_rcg2_determine_rate+0x1c/0x28 [3.409387] clk_core_determine_round_nolock+0x58/0xe4 [3.421414] clk_core_round_rate_nolock+0x48/0xfc [3.432974] clk_core_round_rate_nolock+0xd0/0xfc [3.444483] clk_core_set_rate_nolock+0x8c/0x300 [3.455886] clk_set_rate+0x38/0x14c 为两个时钟添加缺少的 parent_map 属性，并且也取消内联 parent_data，以使匹配的 parent_map 和 parent_data 保持在一起。(CVE-2024-58076)

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

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

  - 在 Linux 内核中，以下漏洞已得到解决：rxrpc：修复对收到的连接中止的处理 修复对收到的连接中止的处理。尽管中止发生在连接级别，但它需要传播到该连接上的调用。在执行传播操作时，调用并没有被唤醒去处理其终止，由于没有进一步的输入，它们只是挂起。还添加了对连接中止日志记录的一些跟踪。(CVE-2024-58053)

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

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

  - 在 Linux 内核中，解决了以下漏洞：ubifs：当 zroot 为空时，跳过转储 tnc 树 清除 slab 缓存将释放内存中的所有 znode 并使 c->zroot.znode = NULL，然后转储 tnc 树将访问 c ->zroot.znode，从而造成空指针取消引用。(CVE-2024-58058)

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

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

  - 在 Linux 内核中，已解决以下漏洞：tomoyo：避免在 tomoyo_write_control() 中发出警告。syzbot 在 tomoyo_write_control() 报告了过大分配警告，因为用户可以写入极长且没有换行符的行。为修复此警告，我使用了 __GFP_NOWARN 而不是检查 KMALLOC_MAX_SIZE，因为实际上有效行应始终短于 32KB（适用“小到不会失败”的内存分配规则）。用户可能会尝试写入超过 32KB 的有效行，但此类请求会因 -ENOMEM 而失败。因此，我认为单独对
    超过 KMALLOC_MAX_SIZE 的行返回 -EINVAL 是冗余的。无需区分超过 32KB 和超过 KMALLOC_MAX_SIZE。(CVE-2024-58085)

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

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

  - 在 Linux 内核中，解决了下列漏洞：OPP：修复了带宽表未初始化时的 dev_pm_opp_find_bw_*() 如果驱动程序调用 dev_pm_opp_find_bw_ceil/floor() 从 OPP 表检索带宽但未创建带宽表，原因是如果 OPP 使用者节点中缺少互连属性，内核将崩溃并显示：无法处理虚拟地址 0000000000000004 上的内核空指针取消引用 ... pc : _read_bw+0x8/0x10 lr：
    _opp_table_find_key+0x9c/0x174 ... 调用追踪：_read_bw+0x8/0x10 (P) _opp_table_find_key+0x9c/0x174 (L)
    _find_key+0x98/0x168 dev_pm_opp_find_bw_ceil+0x50/0x88 ... 为了修复此崩溃，在尝试使用 _read_bw() 获取带宽之前，创建断言函数检查是否已创建带宽表。
    (CVE-2024-58068)

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

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

  - 在 Linux 内核中，以下漏洞已得到解决： netfilter: nf_tables: reject mismatching sum of field_len with set key length 字段长度说明提供了连接中每个分隔键字段的长度，每个字段都被四舍五入到 32 位，以计算 pipapo_init() 中的 pipapo 规则宽度。设置密钥长度可提供对齐为 32 位的密钥总大小。
    基于寄存器的运算仍允许将不匹配的密钥集长度和字段长度描述结合起来，例如，密钥集长度为 10，字段描述为 [ 5, 4 ]，则 pipapo 宽度为 12。
    (CVE-2025-21826)

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

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

  - 在 Linux 内核中，已解决以下漏洞：drm/v3d：如果活动 perfmon 正在被破坏，则将其停止如果活动性能监视器 (`v3d->active_perfmon`) 正在被破坏，请首先将其停止。目前，活动 perfmon 在析构期间不会停止，从而使“v3d->active_perfmon”指针过时。这可导致未定义的行为和不稳定。此修补程序可确保活动 perfmon 在销毁前停止，这与提交 7d1fd3638ee3 中引入的行为保持一致（drm/v3d：在破坏前停止活动 perfmon）。(CVE-2024-58086)

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

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

  - 在 Linux 内核中，解决了以下漏洞：team：防止添加已是下级团队设备的设备 防止添加已是下级团队设备的设备，例如，如果已添加 vlan1 且 veth0 是 vlan1 的下级，则添加 veth0。这在实践中无用，并且会导致递归锁定：$ ip 链接添加 veth0 类型 veth 对等机名称 veth1 $ ip 链接设置 veth0 up $ ip 链接设置 veth1 up $ ip 链接添加链接 veth0 名称 veth0.1 类型 vlan protocol 802.1Q id 1 $ ip 链接添加 team0 type team $ ip 链接设置 veth0.1 down $ ip 链接设置 veth0.1 主 team0 team0： 已添加端口设备 veth0.1 $ ip 链接设置 veth0 down $ ip 链接设置 veth0 主 team0 === ========================================= 警告：
    检测到可能的递归锁定 6.13.0-rc2-virtme-00441-ga14a429069bb #46 未感染
    ------------------------------------------------- ip/7684 正在尝试以获取锁定：ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}，at：team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/ net/team/team_core.c:2973)，但任务已处于锁定状态：
    ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}，at：team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) 其他信息可能帮我们调试这个：可能不安全的锁定方案: CPU0 ---- lock(team->team_lock_key)； lock(team->team_lock_key)； *** DEADLOCK *** 可能是因为缺少由 ip/7684 持有的锁定嵌套符号 2 锁定：堆栈回溯：CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441- ga14a429069bb #46 硬件名称：QEMU 标准 PC (i440FX + PIIX, 1996)，BIOS 1.16.3-debian-1.16.3-2 04/01/2014 调用跟踪：<TASK> dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug .cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ？ team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking /mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers /net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/ dev.c:8993) ?
    __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev .c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117) (CVE-2024-58071)

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

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

  - 在 Linux 内核中，解决了以下漏洞：media：uvcvideo： 修复使用 gpio 单元时取消绑定期间发生的崩溃问题 我们对设备托管功能使用了错误的设备。在应该使用接口设备时，我们使用了 usb 设备。如果我们从 usb 接口取消绑定驱动程序，则永远不会调用清理函数。在我们的示例中，IRQ 从不被禁用。如果触发了 IRQ，它将尝试访问已释放的内存部分，从而导致 OOPS。我们无法在此处使用函数 devm_request_threaded_irq。uvc_delete 释放主结构后，可能会调用 devm_* clean 函数。幸运的是，此缺陷的影响很小，因为它仅受到具有 gpio 单元的设备影响，并且用户必须取消绑定设备，断开连接不会触发此错误。(CVE-2024-58079)

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

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

  - 在 Linux 内核中，已解决以下漏洞：KVM：在 kvm_get_vcpu() 中明确验证目标 vCPU 处于在线状态 在 kvm_get_vcpu() 中限定索引之前，明确验证目标 vCPU 处于完全在线状态。如果索引错误，nospec 限定将生成“0”，即 KVM 将返回 vCPU0 而不是 NULL。实际上，该缺陷不太可能造成问题，因为仅当用户空间或来宾机有缺陷或行为不当时（例如 KVM 可能向 vCPU0 发送中断，而不是将其丢弃）时它才会起作用。不过，由于 KVM 为 vCPUs 数组使用了 xarray，因此在向用户空间发布 vCPU 之前（参见提交 c5b077549136 (KVM：将 kvm->vcpus 数组转换为 xarray)），也就是在保证 vCPU 创建成功之前，在 online_vcpus 中返回不应该存在的 vCPU0 是有问题的。因此，如果 vCPU0 被取消引用，而 kvm_vm_ioctl_create_vcpu() 因错误退出 vCPU 创建并释放 vCPU0，那么错误地提供对 vCPU0 的访问将触发使用后释放。提交 afb2acb2e3a3（KVM：修复 vcpu_array[0] 竞赛）掩盖了这一问题，但同时也带来了一个无法解决的拆卸难题。在 vCPU0 完全联机之前阻止对其进行访问，将允许恢复提交 afb2acb2e3a3，而不会重新引入 vcpu_array[0] UAF 争用。(CVE-2024-58083)

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

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

  - 在 Windows 系统上，遭到入侵的内容进程可能会使用通过 AudioIPC 发送的错误 StreamData，以在浏览器进程中触发释放后使用。这可能会导致沙盒逃逸。此漏洞会影响 Firefox < 136、Firefox ESR < 115.21、Firefox ESR < 128.8、Thunderbird < 136 和 Thunderbird < 128.8。
    (CVE-2025-1930)

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

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

  - 在 Linux 内核中，解决了以下漏洞：crypto: tegra - tegra init 失败时不传输 req 函数 tegra_cmac_init 或 tegra_sha_init 可能会在内存耗尽时返回错误。当它们返回错误时，不应传输请求。(CVE-2024-58075)

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

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

  - 在 Linux 内核中，解决了下列漏洞：misc：misc_minor_alloc 为所有动态/misc 动态未使用 ida misc_minor_alloc 仅在 MISC_DYNAMIC_MINOR 的情况下使用 ida 为次要的分配 ID，但 misc_minor_free 始终使用造成不匹配的 ida_free 释放 ID和以下警告： > > 警告：CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f > > ida_free 调用了未分配的 id=127。 > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ... > > [<60941eb4>] ida_free+0x3e0/0x41f > > [<605ac993>] misc_minor_free+0x3e/0xbc > > [<605acb82>] misc_deregister+0x171/0x1b3 misc_minor_alloc 已更改为从 ida 为落在 dynamic/ misc 动态次要对象范围内的所有次要对象分配 id (CVE-2024-58078)

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

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

  - 在 Linux 内核中，已解决以下漏洞： RDMA/rxe： 修复警告
    __rxe_cleanup+0x12c/0x170 [rdma_rxe] 调用追踪如下所示：<TASK> ? show_regs.cold+0x1a/0x1f ？
    __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __warn+0x84/0xd0 ？ __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? report_bug+0x105/0x180？ handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ？ asm_exc_invalid_op+0x1b/0x20 ？
    __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __rxe_cleanup+0x124/0x170 [rdma_rxe] rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe] ib_destroy_qp_user+0x118/0x190 [ib_core] rdma_destroy_qp.cold+0x43/0x5e [rdma_cm] rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core] rtrs_srv_close_work.cold+ 0x1b/0x31 [rtrs_server] process_one_work+0x21d/0x3f0 worker_thread+0x4a/0x3c0 ？ process_one_work+0x3f0/0x3f0 kthread+0xf0/0x120 ？ kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> 分配了过多 rdma 资源时，rxe 需要更多时间来处理这些 rdma 资源。由于当前超时，rxe 有时无法正确释放 rdma 资源。与其他 rdma 驱动程序相比，超时时间更长。
    (CVE-2025-21829)

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

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

  - 在 Linux 内核中，解决了以下漏洞：usb：gadget：f_tcm：不立即释放命令 不提早释放命令。等待感知状态的状态完成。然后可以将其释放。否则，我们将双重释放命令。(CVE-2024-58055)

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

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

  - 在 Linux 内核中，以下漏洞已解决：rtc：pcf85063：修复了 PCF85063 NVMEM 读取中潜在的 OOB 写入。nvmem 接口支持可变的缓冲区大小，而 regmap 接口使用固定大小的存储运行。如果 nvmem 客户端使用的缓冲区大小小于 4 个字节，regmap_read 将会越界写入，因为它预期缓冲区会指向未签名的 int。通过使用中介未签名的 int 来保存值以修复此问题。(CVE-2024-58069)

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

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

  - Linux 内核中，已解决下列漏洞：固件：qcom：scm：修复 qcom_scm_get_tzmem_pool() Commit 中缺少的读取屏障 2e4955167ec5（固件：qcom：scm：修复 __scm 和 waitq 完成变量初始化）在探测中引入了写入屏障函数存储全局“__scm”变量。我们所有已知的屏障都是配对的（参见 memory-barriers.txt： 请注意，写入障碍通常应与读取障碍或地址依赖障碍配对），因此从并发上下文访问它需要读取障碍。之前的提交在 qcom_scm_is_available() 中添加了此类屏障，因此我们可以直接使用。缺乏这种读取障碍会导致获取过时的“__scm ”变量值 NULL 并取消引用。请注意，qcom_scm_is_available() 中的 barrier 可在此处满足控制依存关系。
    (CVE-2024-58084)

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

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

  - 在 systemd 253 中发现了问题。攻击者可以截断密封的日志文件，然后恢复日志密封，这样尽管日志文件被修改，但检查完整性时也不会显示错误。请注意：据报告，供应商在回复中否认任何发现都是安全漏洞。(CVE-2023-31438)

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

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

  - 在 Linux 内核中，解决了以下漏洞：clk：qcom：dispcc-sm6350：为时钟添加缺少的 parent_map 若 clk_rcg2 有父项，则其应业已定义 parent_map，否则当我们像下面这样调用 clk_set_rate 时，将遭遇空指针取消引用： [3.388105] 调用跟踪：[3.390664] qcom_find_src_index+0x3c/0x70 (P) [3.395301] qcom_find_src_index+0x1c/0x70 (L) [3.399934]
    _freq_tbl_determine_rate+0x48/0x100 [3.404753] clk_rcg2_determine_rate+0x1c/0x28 [3.409387] clk_core_determine_round_nolock+0x58/0xe4 [3.421414] clk_core_round_rate_nolock+0x48/0xfc [3.432974] clk_core_round_rate_nolock+0xd0/0xfc [3.444483] clk_core_set_rate_nolock+0x8c/0x300 [3.455886] clk_set_rate+0x38/0x14c 在时钟缺少 parent_map 的地方添加该属性，并取消内联 parent_data，以使匹配的 parent_map 和 parent_data 始终匹配在一起。(CVE-2024-58080)

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

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

  - 在 Linux 内核中，以下漏洞已解决：wifi：rtlwifi：删除未使用的 check_buddy_priv 提交 2461c7d60f9f（rtlwifi：更新标头文件）引入了私有数据结构的全局列表。之后，提交 26634c4b1868（rtlwifi 修改现有位以匹配供应商版本 2013.02.07）开始在探测时向该列表添加隐私数据，并添加了挂钩 check_buddy_priv 以查找来自类似设备的隐私数据。但该函数从未被使用。此外，虽然该列表存在锁定，但从未被使用过。而且，当探测失败时，隐私数据从不会从列表中删除。这会造成第二个探测访问已释放的内存。删除未使用的挂钩、结构和成员，这将防止列表中潜在的争用条件，以及在探测失败时第二次探测期间造成的损坏。(CVE-2024-58072)

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

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

  - 在 Linux 内核中，以下漏洞已得到解决：Landlock： 处理奇怪的文件 已损坏的文件系统（如 bcachefs）可能会返回奇怪的文件。不会发出警告并允许访问此类文件，而是将其视为常规文件。(CVE-2025-21830)

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

ID	名称	严重性
232311	Linux Distros 未修补的漏洞：CVE-2023-45913	medium
232310	Linux Distros 未修补的漏洞：CVE-2023-45919	medium
232309	Linux Distros 未修补的漏洞：CVE-2023-45922	medium
232308	Linux Distros 未修补的漏洞：CVE-2023-45931	high
232307	Linux Distros 未修补的漏洞：CVE-2007-1266	high
232306	Linux Distros 未修补的漏洞：CVE-2014-9066	medium
232305	Linux Distros 未修补的漏洞：CVE-2021-28689	medium
232302	Acclaim Systems USAHERDS Web 检测	info
232293	已安装 Termius (Linux)	info
232288	LibreOffice 24.8.x < 24.8.5 / 25.2.x < 25.2.1 (cve-2025-1080)	critical
232276	Linux Distros 未修补的漏洞: CVE-2025-21831	high
232275	Linux Distros 未修补的漏洞: CVE-2024-58057	medium
232274	Linux Distros 未修补的漏洞: CVE-2024-58063	medium
232273	Linux Distros 未修补的漏洞: CVE-2025-21828	medium
232272	Linux Distros 未修补的漏洞: CVE-2024-58082	medium
232271	Linux Distros 未修补的漏洞: CVE-2025-21825	medium
232270	Linux Distros 未修补的漏洞: CVE-2023-31439	medium
232269	Linux Distros 未修补的漏洞: CVE-2024-58074	critical
232268	Linux Distros 未修补的漏洞: CVE-2024-58081	medium
232267	Linux Distros 未修补的漏洞: CVE-2024-58062	critical
232266	Linux Distros 未修补的漏洞: CVE-2025-26699	medium
232265	Linux Distros 未修补的漏洞: CVE-2025-21832	medium
232264	Linux Distros 未修补的漏洞：CVE-2024-58077	medium
232263	Linux Distros 未修补的漏洞: CVE-2024-58054	medium
232262	Linux Distros 未修补的漏洞：CVE-2024-58051	medium
232261	Linux Distros 未修补的漏洞: CVE-2025-21833	critical
232260	Linux Distros 未修补的漏洞：CVE-2024-58056	medium
232259	Linux Distros 未修补的漏洞：CVE-2024-58052	medium
232258	Linux Distros 未修补的漏洞: CVE-2023-31437	medium
232257	Linux Distros 未修补的漏洞：CVE-2024-58076	medium
232256	Linux Distros 未修补的漏洞：CVE-2024-58053	medium
232255	Linux Distros 未修补的漏洞：CVE-2024-58058	medium
232254	Linux Distros 未修补的漏洞：CVE-2024-58085	high
232253	Linux Distros 未修补的漏洞: CVE-2024-58068	medium
232252	Linux Distros 未修补的漏洞: CVE-2025-21826	critical
232251	Linux Distros 未修补的漏洞: CVE-2024-58086	medium
232250	Linux Distros 未修补的漏洞: CVE-2024-58071	medium
232249	Linux Distros 未修补的漏洞: CVE-2024-58079	medium
232248	Linux Distros 未修补的漏洞: CVE-2024-58083	high
232247	Linux Distros 未修补的漏洞: CVE-2025-1930	high
232246	Linux Distros 未修补的漏洞: CVE-2024-58075	medium
232245	Linux Distros 未修补的漏洞：CVE-2024-58078	medium
232244	Linux Distros 未修补的漏洞: CVE-2025-21829	medium
232243	Linux Distros 未修补的漏洞: CVE-2024-58055	high
232242	Linux Distros 未修补的漏洞: CVE-2024-58069	high
232241	Linux Distros 未修补的漏洞: CVE-2024-58084	high
232240	Linux Distros 未修补的漏洞: CVE-2023-31438	medium
232239	Linux Distros 未修补的漏洞: CVE-2024-58080	medium
232238	Linux Distros 未修补的漏洞: CVE-2024-58072	medium
232237	Linux Distros 未修补的漏洞: CVE-2025-21830	critical

检测

Nessus 的 Misc. 系列

medium

medium

medium

high

high

medium

medium

info

info

critical

high

medium

medium

medium

medium

medium

medium

critical

medium

critical

medium

medium

medium

medium

medium

critical

medium

medium

medium

medium

medium

medium

high

medium

critical

medium

medium

medium

high

high

medium

medium

medium

high

high

high

medium

medium

medium

critical