远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-572.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，已解决以下漏洞：arm64: cacheinfo: 避免越界写入 cacheinfo 数组。检测或填充缓存信息的循环已在数组大小上存在边界检查，但不会考虑具有单独数据或指令缓存的缓存级别。通过增加任何填充的叶（而非任意填充的级别）的索引修复此问题。 (CVE-2025-21785)

  - 在 Linux 内核中，已解决以下漏洞：powerpc/xive/spapr: correct bitmap allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 调用跟踪：
    [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0]
    _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [ c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0
    __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 该缺陷地址所属的对象位于 c00000001d1d0118， 属于大小为 8 的缓存 kmalloc-8 该缺陷地址位于 8 字节区域内的 0 个字节 [c00000001d1d0118, c00000001d1d0120) 该缺陷地址所属的实体页面为：page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address:
    c00000001d1d0000： fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080： fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100： fc fc fc fc fc fc 02 fc fc fc fc fc ^ c00000001d1d0180： fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200： fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc 出现这种情况是因为使用了错误的分配单位（位），而不是通过 (BITS_TO_LONGS(count) * sizeof(long)) 或同等条件。对于少量位，分配的对象可能小于 sizeof(long)，从而导致无效访问。使用 bitmap_zalloc() 分配和初始化 irq 位图，与 bitmap_free() 配对使用以确保一致性。 (CVE-2022-49623)

  - 在 Linux 内核中，已解决以下漏洞：soc: qcom: cmd-db: 将共享内存映射为 WC，而非 WB。Linux 不写入 cmd-db 区域。此内存区域受到 XPU 的写入保护。
    XPU 有时误将干净缓存清理检测为写入受保护区域，导致安全中断，从而在信任区中的某处出现死循环。XPU 现在正常工作的唯一原因是 Qualcomm Hypervisor 将相同的区域映射为 Stage 2 转换表中的 Non-Cacheable 内存。如使用对此类特定映射一无所知的其他管理程序（如 Xen 或 KVM），则会出现此问题。将 cmd-db 内存的映射从 MEMREMAP_WB 更改为 MEMREMAP_WT/WC 可移除对 Stage 2 表中正确映射的依赖关系。此修补程序通过更新映射到 MEMREMAP_WC 来修复该问题。我在 SA8155P 上使用 Xen 进行了测试。 (CVE-2024-46689)

  - 在 Linux 内核中，已解决以下漏洞：io_uring: 检查溢出刷新期间是否需要重新计划。通常，此列表为空或仅包含少量条目。如应用程序的确发生了溢出，此列表也会产生部分条目。但是，像 syzbot 这样的模糊测试工具会生成大量的溢出条目，导致刷新过程需要很长时间。在刷新时检查是否需要重新安排，并在必要时解锁。
    由于溢出总是从列表头部删除，因此不需要维护复杂的状态，从而可以安全地在每次循环迭代结束时暂时释放并重新获取锁。(CVE-2024-50060)

  - 在 Linux 内核中，已解决以下漏洞：io_uring/rw：修复 O_DIRECT 开始写入所缺少的 NOWAIT 检查。当 io_uring 启动写入时，会调用 kiocb_start_write() 函数来获取超级块的读写信号量，从而防止文件系统在写入过程中冻结。然而，冻结进程将读写信号量置于写入模式，阻止新的写入开始并等待正在进行的写入完成。但是 io_uring 总是调用 kiocb_start_write() 函数，从而在冻结进程已经运行的情况下导致该函数阻塞的问题。该问题会进一步造成死锁，即冻结进程正在等待写入完成，但是写入无法完成，因为调用的函数一直处于阻塞状态。最终导致以下进程卡住，使其在尝试启动新的写入时受到阻止：task:fio state:D stack:0 pid:886 tgid:886 ppid:876 调用跟踪：__switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8
    __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110
    __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO:
    任务 fsfreeze:7364 阻断超过 15 秒。Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18
    __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 使 io_uring 遵循 IOCB_NOWAIT 标志进行修复，且在设置标志时避免阻塞锁，如果未设置标志，则允许获取阻塞锁。对于始终设置 IOCB_NOWAIT 的正常问题，此函数返回 -EAGAIN，会使 io_uring 核心发出阻断的写入尝试。这反过来也会让完成运行，确保转发进度。由于冻结首先需要 CAP_SYS_ADMIN，因此普通用户无法触发。 (CVE-2024-53052)

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

检测

CentOS 9: kernel-5.14.0-572.el9

high Nessus 插件 ID 232849

版本 1.1