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

  - btrfs：始终等待有序盘区以避免 OE 争用 [缺陷] Syzbot 报告一个缺陷，同一范围内可能存在冲突的 OE： BTRFS 危急 （device loop4）：insert_ordered_extent：264 中的错误：
    重叠有序盘区，现有 OE file_offset 16384 num_bytes 430080 标记0x1089，新 OE file_offset 16384 num_bytes 430080 标记0x80 （errno=-17 对象 alrea[ 179.162726][ T6897] BTRFS 危急 （device loop4）：insert_ordered_extent：264 中的错误：重叠有序盘区，现有 OE file_offset 16384 num_bytes 430080 标记0x1089，新 OE file_offset 16384 num_bytes 430080 标记0x80（errno=-17 对象已存在）------------[ cut here ]------------ fs/btrfs/ordered-data 处的内核缺陷。C：264！硬件名称：Google Google Compute Engine/Google Compute Engine、BIOS Google 05/09/2026 RIP：
    0010：btrfs_alloc_ordered_extent+0x943/0xad0 调用跟踪： <TASK> cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990
    __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
    ---[ end trace 000000000000000000 ]--- [CAUSE] Since commit ff66fe666233（btrfs：修复针对附加直接写入的错误缓冲 IO 回退），如果直接 IO 完成较短，我们会将 isize 恢复回原始 isize，以便在缓冲的回退期间可遵守附加写入。通常，在缓冲的回写期间，我们依靠 lock_and_cleanup_extent_if_need（） 函数等待任何现有的有序盘区。但只有当start_pos位于 isize 内时，才会发生有序盘区等待。由于我们已在失败的直接 IO 期间恢复 isize，因此不会等待任何有序盘区。这意味着我们可发生争用，其中直接 IO OE 仍在树中、已完成但尚未删除，然后我们要为缓冲写入插入 OE，从而导致上述崩溃。[修复]使 OE 无条件等待，以处理恢复的 isize 情况。由于 lock_and_cleanup_extent_if_need（） 现在可以锁定盘区或返回 -EAGAIN，因此还要删除处理非盘区锁定情况的分支，并对其重命名以删除_if_need后缀。以下微基准测试显示了 btrfs_buffered_write（） 的运行时间差异，执行“xfs_io -f -c pwrite 0 1m”工作负载，所有值都是以纳秒为单位的平均运行时间。函数运行时 |之前 |之后
    -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need（） | 58.2183.0 |btrfs_buffered_write（） | 2115.62973.3 |btrfs_buffered_write（） 的整体运行时间仍然很小（仍然不到 3 微秒），我想说额外的成本仍然是可以接受的。修复此问题的替代方法是在 iomap_end（） 期间等待有序盘区，此时完成 isize 恢复。但该解决方案将破坏 nowait 要求，就像 nowait 直接 IO 结束较短一样，我们必须无条件等待 OE，否则下一个附加缓冲的 IO 仍会遇到同样的问题。所以这里我们必须将等待成本转移到缓冲写入，但至少代码稍微精简一些。（CVE-2026-90264）

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

检测

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

medium Nessus 插件 ID 347831

版本 1.11