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

  - bpf、x86：修复扩展寄存器的每个 CPU 地址解析 每个 CPU 地址 MOV 的目标以 ModRM.reg 编码，并由 REX 扩展。R，但 REX 前缀使用 add_1mod（） 构建，它设置了 REX.B. REX。B 扩展了 ModRM.rm 和 SIB.base，而该指令将内存寻址为没有基数的 disp32，因此该位根本没有任何影响，高位寄存器位就会丢失。因此，每个 is_ereg（） 目标都会解析到错误的寄存器，选择共享低三位的寄存器：R5
    -> RAX R7 -> RBP R8 -> RSI R9 -> RDI 如果 BPF_REG_5 reg2hex 为 0，则发出的 65 49 03 04 25 <off> 加上 %gs：<off>，%rax 会向 RAX 而不是 R8 添加每 CPU 的偏移。目标保留未调整的地址，而 RAX 被重写，因此程序会继续取消引用从未按 CPU 创建的指针：
    缺陷：无法处理地址的页面错误：0000607e386a8894 RIP：
    bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9 调用跟踪：__bpf_prog_test_run_raw_tp+0x2dc/0x7d0
    __flush_smp_call_function_queue+0x1e9/0xc80 内核错误 - 不同步：中断 R5 中的致命异常是四个异常中最轻微的，它会使擦除寄存器产生别名，并在存储中发生错误。R7 别名 RBP 且会损坏帧指针，R8 和 R9 别名会损坏参数寄存器。使用 add_2mod（） 以便寄存器通过 REX。R，匹配 add_2reg（） 将其放置在 ModRM.reg 中的方式以及 emit_priv_frame_ptr（） 硬编码0x4c与 R9 相同的指令的方式。非扩展寄存器的编码保持不变。尝试恢复 BPF_GCC CI 时出现问题（利用 BPF_GCC 构建的自我测试）。由于 clang 在每次 per-CPU 访问之前都会将地址重新加载到 R1，因此目的地永远不会是扩展寄存器，因此此问题没有受到注意。GCC 同时维持数个 per-CPU 地址处于活动状态，且test_progs bpf_gcc会在 global_percpu_data/init 中造成内核恐慌，其中 .percpu 变量的地址会在 R5 结束。（CVE-2026-89581）

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

检测

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

high Nessus 插件 ID 345368

版本 1.1