Linux Kernel BPF Verifier bpf_compute_live_registers zext_dst erweiterte Rechte

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
8.0$0-$5k3.90+

Zusammenfassunginfo

In Linux Kernel wurde eine sehr kritische Schwachstelle gefunden. Es geht um die Funktion bpf_compute_live_registers der Komponente BPF Verifier. Mit der Manipulation des Arguments zext_dst mit unbekannten Daten kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. Diese Schwachstelle wird als CVE-2026-98869 gehandelt. Der Angriff kann über das Netzwerk angegangen werden. Es ist kein Exploit verfügbar. Es wird empfohlen, einen Patch anzuwenden, um dieses Problem zu beheben.

Detailsinfo

Es wurde eine Schwachstelle in Linux Kernel - die betroffene Version ist nicht klar definiert - entdeckt. Sie wurde als sehr kritisch eingestuft. Es betrifft die Funktion bpf_compute_live_registers der Komponente BPF Verifier. Durch die Manipulation des Arguments zext_dst mit einer unbekannten Eingabe kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. Im Rahmen von CWE wurde eine Klassifizierung als CWE-20 vorgenommen. Auswirkungen hat dies auf Vertraulichkeit, Integrität und Verfügbarkeit. Die Zusammenfassung von CVE lautet:

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")

Bereitgestellt wird das Advisory unter git.kernel.org. Die Identifikation der Schwachstelle wird seit dem 25.09.2026 mit CVE-2026-98869 vorgenommen. Sie gilt als leicht ausnutzbar. Der Angriff kann über das Netzwerk erfolgen. Um eine Ausnutzung durchzusetzen, muss eine erweiterte Authentisierung umgesetzt werden. Eine Ausnutzung erfordert, dass das Opfer eine spezifische Handlung durchführt. Es sind zwar technische Details, jedoch kein verfügbarer Exploit zur Schwachstelle bekannt. Ein Exploit zur Schwachstelle wird momentan etwa USD $0-$5k kosten (Preisberechnung vom 21.10.2026).

Die Schwachstelle lässt sich durch das Einspielen des Patches 7ce090afbf725e25fff29caacce1eaf8459b1117 lösen.

Unter anderem wird der Fehler auch in der Verwundbarkeitsdatenbank von EUVD (EUVD-2026-107288) dokumentiert. If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Produktinfo

Typ

Hersteller

Name

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 8.4
VulDB Meta Temp Score: 8.0

VulDB Base Score: 8.4
VulDB Temp Score: 8.0
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Erweiterte Rechte
CWE: CWE-20
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Patch
Status: 🔍

0-Day Time: 🔒

Patch: 7ce090afbf725e25fff29caacce1eaf8459b1117

Timelineinfo

25.09.2026 CVE zugewiesen
21.10.2026 +26 Tage Advisory veröffentlicht
21.10.2026 +0 Tage VulDB Eintrag erstellt
21.10.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2026-98869 (🔒)
GCVE (CVE): GCVE-0-2026-98869
GCVE (VulDB): GCVE-100-424845
EUVD: 🔒

Eintraginfo

Erstellt: 21.10.2026 17:23
Aktualisierung: 21.10.2026 18:14
Anpassungen: 21.10.2026 17:23 (58), 21.10.2026 18:14 (1)
Komplett: 🔍
Cache ID: 216::103

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Might our Artificial Intelligence support you?

Check our Alexa App!