{"id":21503,"date":"2026-09-12T04:31:16","date_gmt":"2026-09-11T20:31:16","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89581"},"modified":"2026-09-12T04:31:16","modified_gmt":"2026-09-11T20:31:16","slug":"cve-2026-89581","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89581","title":{"rendered":"CVE-2026-89581 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, x86: Fix per-CPU"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>bpf, x86: Fix per-CPU address resolution into an extended register<\/p>\n<p>The destination of the per-CPU address MOV is encoded in ModRM.reg,<br \/>\nwhich is extended by REX.R, but the REX prefix is built with<br \/>\nadd_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and<br \/>\nthis instruction addresses memory as disp32 with no base, so the bit<br \/>\nhas no effect at all and the high register bit is simply lost.<\/p>\n<p>Every is_ereg() destination therefore resolves to the wrong register,<br \/>\npicking whichever one shares the low three bits:<\/p>\n<p>  R5 -&gt; RAX    R7 -&gt; RBP    R8 -&gt; RSI    R9 -&gt; RDI<\/p>\n<p>With BPF_REG_5, whose reg2hex is 0, the emitted<\/p>\n<p>  65 49 03 04 25 \tadd %gs:,%rax<\/p>\n<p>adds the per-CPU offset to RAX rather than R8. The destination keeps<br \/>\nthe unadjusted address and RAX is clobbered, so the program goes on to<br \/>\ndereference a pointer that was never made per-CPU:<\/p>\n<p>  BUG: unable to handle page fault for address: 0000607e386a8894<br \/>\n  RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93\/0xc9<br \/>\n  Call Trace:<br \/>\n   __bpf_prog_test_run_raw_tp+0x2dc\/0x7d0<br \/>\n   __flush_smp_call_function_queue+0x1e9\/0xc80<br \/>\n  Kernel panic &#8211; not syncing: Fatal exception in interrupt<\/p>\n<p>R5 is the mildest of the four, aliasing a scratch register and faulting<br \/>\nat the store. R7 aliases RBP and would corrupt the frame pointer, R8<br \/>\nand R9 alias the argument registers.<\/p>\n<p>Use add_2mod() so the register goes through REX.R, matching how<br \/>\nadd_2reg() places it in ModRM.reg and how emit_priv_frame_ptr()<br \/>\nhardcodes 0x4c for the same instruction with R9. Encodings for the<br \/>\nnon-extended registers are unchanged.<\/p>\n<p>Problem showed up when trying to resurrect BPF_GCC CI (selftests built<br \/>\nwith BPF_GCC).<\/p>\n<p>This has gone unnoticed because clang reloads the address into R1<br \/>\nbefore each per-CPU access, so the destination is never an extended<br \/>\nregister. GCC keeps several per-CPU addresses live at once, and<br \/>\ntest_progs-bpf_gcc panics the kernel in global_percpu_data\/init, where<br \/>\nthe address of a .percpu variable ends up in R5.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>bpf, x86: Fix per-CPU address resolution into an extended register<\/p>\n<p>The destination of the per-CPU address MOV is encoded in ModRM.<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21503","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21503","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21503"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21503"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21503"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}