Odebrany

CVE-2026-89581

opublikowano: 11.09.2026, 22:19

modyfikacja: 11.09.2026, 22:19

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

bpf, x86: Napraw rozpoznawanie adresów dla poszczególnych procesorów w rozszerzonym rejestrze

Miejsce docelowe adresu MOV na procesor jest zakodowane w ModRM.reg,
który jest rozszerzony przez REX.R, ale przedrostek REX jest zbudowany z
add_1mod(), która ustawia REX.B. REX.B rozszerza ModRM.rm i SIB.base oraz
ta instrukcja adresuje pamięć jako disp32 bez bazy, więc bit
nie ma żadnego efektu, a bit górnego rejestru jest po prostu tracony.

Dlatego każde miejsce docelowe is_ereg() prowadzi do niewłaściwego rejestru,
wybierając ten, który ma wspólne trzy dolne bity:

R5 -> RAX R7 -> RBP R8 -> RSI R9 -> RDI

W przypadku BPF_REG_5, którego reg2hex wynosi 0, emitowany jest

65 49 03 04 25 <off> dodaj %gs:<off>,%rax

dodaje przesunięcie na procesor do RAX zamiast R8. Cel pozostaje
nieskorygowany adres i RAX są zablokowane, więc program kontynuuje działanie
wyłuskaj wskaźnik, który nigdy nie został utworzony dla każdego procesora:

BŁĄD: nie można obsłużyć błędu strony dla adresu: 0000607e386a8894
RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9
Zadzwoń do śledzenia:
__bpf_prog_test_run_raw_tp+0x2dc/0x7d0
__flush_smp_call_function_queue+0x1e9/0xc80
Panika jądra – brak synchronizacji: krytyczny wyjątek w przerwaniu

R5 jest najłagodniejszym z czterech, aliasuje rejestr podstaw i błędy
w sklepie. R7 aliasuje RBP i uszkodzi wskaźnik ramki, R8
i R9 alias rejestrów argumentów.

Użyj add_2mod(), aby rejestr przeszedł przez REX.R, dopasowując sposób
add_2reg() umieszcza go w ModRM.reg i jak emit_priv_frame_ptr()
kody stałe 0x4c dla tej samej instrukcji z R9. Kodowania dla
rejestry nierozszerzone pozostają bez zmian.

Problem pojawił się przy próbie wskrzeszenia BPF_GCC CI (zbudowano autotesty
z BPF_GCC).

Pozostało to niezauważone, ponieważ clang ponownie ładuje adres do R1
przed każdym dostępem do procesora, więc miejsce docelowe nigdy nie jest rozszerzane
zarejestruj się. GCC utrzymuje jednocześnie kilka adresów na procesor i
test_progs-bpf_gcc panikuje jądro w global_percpu_data/init, gdzie
adres zmiennej .percpu kończy się na R5.

In the Linux kernel, the following vulnerability has been resolved:

bpf, x86: Fix per-CPU address resolution into an extended register

The destination of the per-CPU address MOV is encoded in ModRM.reg,
which is extended by REX.R, but the REX prefix is built with
add_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and
this instruction addresses memory as disp32 with no base, so the bit
has no effect at all and the high register bit is simply lost.

Every is_ereg() destination therefore resolves to the wrong register,
picking whichever one shares the low three bits:

R5 -> RAX R7 -> RBP R8 -> RSI R9 -> RDI

With BPF_REG_5, whose reg2hex is 0, the emitted

65 49 03 04 25 <off> add %gs:<off>,%rax

adds the per-CPU offset to RAX rather than R8. The destination keeps
the unadjusted address and RAX is clobbered, so the program goes on to
dereference a pointer that was never made per-CPU:

BUG: unable to handle page fault for address: 0000607e386a8894
RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9
Call Trace:
__bpf_prog_test_run_raw_tp+0x2dc/0x7d0
__flush_smp_call_function_queue+0x1e9/0xc80
Kernel panic - not syncing: Fatal exception in interrupt

R5 is the mildest of the four, aliasing a scratch register and faulting
at the store. R7 aliases RBP and would corrupt the frame pointer, R8
and R9 alias the argument registers.

Use add_2mod() so the register goes through REX.R, matching how
add_2reg() places it in ModRM.reg and how emit_priv_frame_ptr()
hardcodes 0x4c for the same instruction with R9. Encodings for the
non-extended registers are unchanged.

Problem showed up when trying to resurrect BPF_GCC CI (selftests built
with BPF_GCC).

This has gone unnoticed because clang reloads the address into R1
before each per-CPU access, so the destination is never an extended
register. GCC keeps several per-CPU addresses live at once, and
test_progs-bpf_gcc panics the kernel in global_percpu_data/init, where
the address of a .percpu variable ends up in R5.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve