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

  - xfs：修复将 xattrs 添加到叶区块时的自由映射调整 xfs/592 和 xfs/794 在我的测试 VM 上运行 ~20 分钟后，两者都会在叶块自由映射调整代码中触发此断言：
    ASSERT（ichdr->firstused >= ichdr->count * sizeof（xfs_attr_leaf_entry_t） + xfs_attr3_leaf_hdr_size（leaf））;
    在启用了大量调试代码后，我将其缩小到尝试设置具有 namelen=3 和 valuelen=71 的本地扩展属性的 fsstress。这导致条目大小为 80 字节。在xfs_attr3_leaf_add_work开始时，自由映射如下所示： i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 其中 rhs 是超过叶条目数组末尾的第一个字节。这不一致 -- 条目数组在字节 448 处结尾，但 freemap[1] 说有从字节 388 开始的可用空间！到函数结束时，freemap 的状况更差：i 0 base 456 大小 0 rhs 456 计数 47 i 1 base 388 大小 52 rhs 456 count 47 i 2 base 2120 大小 4 rhs 456 count 47 firstused = 440 重要说明：388 与 8 字节的条目数组元素大小不一致。根据错误的自由映射，名称区域从字节 440（即条目数组结尾下方）开始！这就是断言触发和文件系统关闭的原因。我们是怎么走到这里的？首先，请回想一下之前的修补程序，xattr 叶块中的自由映射数组并不是叶块中所有可用空间的综合映射。换句话说，使叶块具有以下函数是完全合法的：* 条目数组使用的 376 字节 * freemap[0] 具有 [base = 376， size = 8] * freemap[1] 具有 [base = 388， size = 1500] * 376 和 388 之间的空间是空闲的，但 freemap 在一段时间前停止跟踪如果我们添加一个 xattr， 条目数组增至 384 字节，freemap[0] 变为 [base = 384， size = 0]。到目前为止，一切都很好。但如果添加第二个 xattr，条目数组将增长到 392 字节，并且 freemap[0] 被上推到 [base = 392， size = 0]。这很糟糕，因为 freemap[1] 尚未更新，现在条目数组和可用空间声明相同的空间。此处的补丁是调整所有自由映射条目，以便它们都不会与条目数组冲突。请注意，此补丁依赖于提交 2a2b5932db6758（xfs：修复属性叶标头 freemap.size 下溢）和之前将零长度自由映射条目重置为 base = 0 的修补程序。（CVE-2026-43158）

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

检测

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

high Nessus 插件 ID 312772

版本 1.30