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

  - btrfs修复 btrfs_clear_space_info_full() 中的不良位字段写入 摘自有关内存屏障排序保证的 memory-barriers.txt 文档: (*) 这些保证不适用于位字段因为编译器经常生成代码以使用非原子 read-修改这些修改写入序列。不尝试使用位字段来同步并行算法。 (*) 即使在位域受到锁保护的情况下给定位域中的所有字段也必须受到锁保护。如果给定位字段中的两个字段受到不同的锁保护则编译器的非原子读取-修改-写入序列可造成对一个字段的更新损坏邻近字段的值。 btrfs_space_info 具有共享基础字的位字段该位字段由字段 full、chunk_alloc 和 flush 组成：struct btrfs_space_info { struct btrfs_fs_info
    * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int claw; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 1762 4 */ ...
    因此为防止并行读取-修改-写入丢失对受锁定保护的其中一个位字段成员的写入对所有位字段的所有写入都必须使用该锁定。除了 btrfs_clear_space_info_full() 会迭代 space_infos 并在不锁定的情况下写出 found->full = 0 外，它们几乎都会执行此操作。假设有一个线程完成了其中 block_group 的删除操作因此在数据回收票证基础架构运行 do_async_reclaim_data_space() 的同时我们调用了 btrfs_clear_space_info_full(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full: 0、chunk_alloc:0、flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READfull: 0, chunk_alloc:0, flush:1 MOD/WRITEfull: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock);返回MOD/WRITEfull:0、chunk_alloc:0、flush:1现在 data_sinfo->flush 为 1但回收工作线程已退出。这破坏了当没有工作排队或运行时刷新为 0 的不变量。一旦违反此不变量，
    __reserve_bytes() 会将票证添加到 space_info->tickets但会将 space_info->flush 设置为 1且不会将工作排入队列。此后，它们将在生成的票证上永远阻断，因为现在不可能再次踢出工作线程。我还通过查看受影响内核的程序集确认它正在执行 RMW 操作。例如要将刷新第3位设置为 0则程序集为andb $0xfb,0x60(%rbx) 以类似的方式将完整第1位设置为 0andb $0xfe,-0x20(%rax)因此我认为这确实是实际系统中的缺陷。我发现许多系统都处于此状态，但目前无法重现。与其将此 footgun 留待将来使用，不如利用 struct 中无论如何还有空间这一事实，并且它已经相当大，只需将三个位域成员更改为 bool 即可。这可避免写入 space_info->full 对 ---truncated--- (CVE-2025-68358)

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

检测

Linux Distros 未修补的漏洞：CVE-2025-68358

medium Nessus 插件 ID 279768

版本 1.27