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

  - ext4：修复 e4b 位图不一致报告 在混合大页面工作负载下的压力测试期间发现一个位图不一致问题。Ext4 报告了多种 e4b 位图检查失败，例如：
    ext4_mb_complex_scan_group：2508：根据组信息，组 350、8179 个释放群集。但得到了 8192 个区块 分析和实验证实，该问题是由页面迁移和位图修改之间的争用条件引起的。虽然这个计时窗口极窄，但在实践中还是被打的：
    folio_lock ext4_mb_load_buddy __migrate_folio检查引用计数folio_mc_copy __filemap_get_folio folio_try_get（folio）......mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock 此问题的根本原因是，load_buddy的快速路径只增加了作品集的引用计数，不足以防止并发作品集迁移。我们观察到作品集迁移过程会获得作品集锁定。因此，我们可以通过检查锁定状态来判断是否在load_buddy中走快速路径。如果 folio 被锁定，我们选择慢速路径（获取锁定）来关闭此并发窗口。此外，此更改还解决了以下问题：启用 DOUBLE_CHECK 宏以检查与位图相关的问题时，可能会触发以下错误：
    Group 324 中字节 784（6272） 处的损坏：f in copy ！= ff on disk/prealloc 分析显示这是误报。存在一个特定的争用窗口，位图和群组描述符会暂时变得不一致，从而导致此错误报告：ext4_mb_load_buddy ext4_mb_load_buddy
    __filemap_get_folio（create|lock） folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio（no lock） ......mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits（e4b->bd_bitmap） folio_unlock 原始逻辑假设由于从磁盘新加载位图时调用 mb_cmp_bitmaps，因此本文档锁定足以防止并发访问。但是，这会忽略一个特定的争用条件：如果另一个进程尝试加载 buddy 并发现作品集已处于最新状态，它将立即开始使用它，而不保持作品集锁定。（CVE-2026-45942）

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

检测

Linux Distros 未修补的漏洞：CVE-2026-45942

high Nessus 插件 ID 317178

版本 1.12