Odebrany

CVE-2026-98869

opublikowano: 21.10.2026, 17:17

modyfikacja: 21.10.2026, 17:17

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: Wnioskuj zext_dst na podstawie analizy żywotności rejestrów statycznych

Jak podano w wątku [1], 32-bitowe operacje weryfikatora wynoszą zero
logika rozszerzenia jest zepsuta. Ta logika jest odpowiedzialna za poprawność
semantyka operacji 32-bitowych na architekturze s390.

Zgodnie z semantyką BPF operacja `w1 += 1` ma wynosić zero
wydłużyć górną połowę rejestru „r1”. Na S390 JIT polega
weryfikator emitujący jawne rozszerzenie zera przed takimi operacjami.

Weryfikator stara się zminimalizować liczbę zerowych rozszerzeń
wstawiane poprzez śledzenie, czy znajdują się górne połówki rejestrów 64-bitowych
kiedykolwiek używany. Wcześniej takie śledzenie działało w następujący sposób:

- pole bpf_reg_state->subreg_def zostało ustawione przez do_check_insn()
dla każdej operacji definiującej dolną, ale nie górną połowę
rejestru.
- Ilekroć weryfikowana była operacja odczytująca cały rejestr,
weryfikator sprawdził subreg_def rejestru i ustawił
bpf_insn_aux_data->zext_dst flagę jako true poprzez wywołanie
funkcja mark_insn_zext().
- Po zakończeniu weryfikacji specjalna przepustka
bpf_opt_subreg_zext_lo32_rnd_hi32() rozszerzone operacje 32-bitowe
z bpf_insn_aux_data->zext_dst ustawionym na true poprzez dodanie
wyraźne rozszerzenie zerowe.

Zauważ, że powyższa logika opiera się na bpf_reg_state->subreg_def,
która jest właściwością bieżącego stanu weryfikatora.
Przed zatwierdzeniem [2] miały miejsce dwa dodatkowe kroki:

- Weryfikator śledził żywotność połówek górnego i dolnego rejestru
flagi REG_LIVE_READ{32,64} w bpf_reg_state->live.
- Funkcja propagate_liveness() o nazwie mark_insn_zext()
w celu przekazania wiedzy o tym, jakie rejestry posiadają
ich górne połówki żyją (i dlatego mogą wymagać zerowego przedłużenia).

Zatwierdzenie [2] usunęła dwa kroki opisane powyżej,
umożliwiając w ten sposób sytuację jak poniżej:

- Górna połowa rejestru jest ustawiona i używana przy jakiejś weryfikacji
ścieżka P1 i tak się składa, że rejestr nie jest oznaczony jako precyzyjny.
- Punkt kontrolny C jest tworzony podczas przetwarzania jakiejś instrukcji
pomiędzy inicjalizacją rejestru a jego użytkowaniem.
- Na innej ścieżce weryfikacji P2 górna połowa rejestru nie jest
zainicjowany, a ścieżka kończy się, docierając do punktu kontrolnego C.
- W takim przypadku zabrakłoby inicjalizacji rejestru na ścieżce P2
zext_dst mark, umożliwiający programowi wstrzyknięcie
dowolną wartość w górnej połowie rejestru.

To zatwierdzenie zastępuje logikę opartą na subreg_def obliczeniem zext_dst
statycznie, jako część analizy bpf_compute_live_registers():

- Analiza śledzi teraz wykorzystanie górnej i dolnej połowy
rejestruje się osobno.
- Jeśli jakaś instrukcja definiuje 32-bitowy podrejestr, ale nie całość
rejestr, *i* górna połowa rejestru od tego momentu żyje
instrukcja, instrukcja jest oznaczona jako zext_dst.

Istnieje jeden zauważalny spadek precyzji: zawsze, gdy jest to podprogram BPF
wywołane, zakłada się, że wszystkie 64 bity rejestrów parametrów są wykorzystane.
Zakłada się, że taki spadek precyzji nie spowodowałby
zauważalny spadek wydajności.

[1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/
[2] commit 107e16979905 („bpf: wyłącz i usuń aktywność opartą na łańcuchu rejestrów”)

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

bpf: Infer zext_dst based on static register liveness analysis

As reported in the thread [1], the verifier's 32-bit operations zero
extension logic is broken. This logic is responsible for correct
semantics of 32-bit operations on s390 architecture.

According to BPF semantics, operation `w1 += 1` is supposed to zero
extend the upper half of the register `r1`. On s390 the JIT relies on
the verifier emitting explicit zero extension before such operations.

The verifier attempts to minimize the amount of zero extensions
inserted by tracking whether upper halves of the 64-bit registers are
ever used. Previously such tracking worked as follows:

- bpf_reg_state->subreg_def field was set by do_check_insn()
for each operation defining lower but not the upper halves
of the register.
- Whenever an operation reading the whole register was verified,
the verifier checked register's subreg_def and set
bpf_insn_aux_data->zext_dst flag as true via a call to
mark_insn_zext() function.
- After the verification was complete, a special pass
bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations
with bpf_insn_aux_data->zext_dst set as true by adding
explicit zero extension.

Note that the logic above relies on bpf_reg_state->subreg_def,
which is a property of a current verifier state.
Before the commit [2] two additional steps happened:

- The verifier tracked upper and lower register halves' liveness as
flags REG_LIVE_READ{32,64} in bpf_reg_state->live.
- The function propagate_liveness() called mark_insn_zext()
in order to transfer the knowledge about which registers have
their upper halves alive (and thus might require zero extension).

The commit [2] removed the two steps described above,
hence making possible a situation like below:

- The register's upper half is set and is used on some verification
path P1 and the register happens not to be marked as precise.
- The checkpoint C is created while processing some instruction
between register initialization and usage.
- On some other verification path P2 the register's upper half is not
initialized and that path ends hitting the checkpoint C.
- In such a case the register's initialization on path P2 would lack
zext_dst mark, making it possible for the program to inject
an arbitrary value in the register's upper half.

This commit replaces subreg_def based logic with computing zext_dst
statically, as a part of the bpf_compute_live_registers() analysis:

- The analysis now tracks usage of upper and lower halves of the
registers separately.
- If some instruction defines a 32-bit subregister, but not the whole
register, *and* the upper half of the register is alive after that
instruction, the instruction is marked as zext_dst.

There is one notable drop in precision: whenever a BPF subprogram is
called, all 64 bits of parameter registers are presumed to be used.
The assumption is that such a drop in precision would not inflict
a noticeable performance penalty.

[1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/
[2] commit 107e16979905 ("bpf: disable and remove registers chain based liveness")

>_ Referencje

https://git.kernel.org/stable/c/7ce090afbf725e25fff29caacce1eaf8459b1117

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