CVE-2026-43009 in Linux
Zusammenfassung
von VulDB • 28.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
bpf: Korrektur der fehlerhaften Pruning aufgrund der atomaren Fetch-Präzisionsverfolgung
Wenn backtrack_insn auf eine BPF_STX-Anweisung mit BPF_ATOMIC und BPF_FETCH trifft, fungiert das src-Register (oder r0 für BPF_CMPXCHG) auch als Ziel, wodurch es den alten Wert aus dem Speicherort empfängt.
Die aktuelle Backtracking-Logik berücksichtigt dies nicht. Sie behandelt atomare Fetch-Operationen gleich wie reguläre Stores, bei denen das src-Register nur ein Eingabewert ist. Dies führt dazu, dass backtrack_insn die Präzision nicht an den Stack-Speicherort weiterleitet, der daraufhin nicht als präzise markiert wird!
Später kann das Pruning von Pfaden im Verifier fälschlicherweise zwei Zustände als äquivalent betrachten, wenn sie sich im Stack-Zustand unterscheiden. Das bedeutet, dass zwei Zweige als äquivalent behandelt und somit ausgepruned werden können, obwohl sie dies nicht sein sollten.
Die Behebung erfolgt wie folgt: Erweitern Sie die BPF_LDX-Behandlung in backtrack_insn, um auch atomare Fetch-Operationen über die Hilfsfunktion is_atomic_fetch_insn() abzudecken. Wenn das Fetch-dst-Register für die Präzisionsverfolgung überwacht wird, löschen Sie es und leiten Sie die Präzision auf den Stack-Slot weiter. Für Nicht-Stack-Speicher stoppt der Präzisions-Walk bei der atomaren Anweisung, genau wie bei regulärem BPF_LDX. Dies deckt alle Fetch-Varianten ab.
Vorher:
0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit
Nachher:
0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=8 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 mark_precise: frame0: regs=r2 stack= before 1: (7b) *(u64 *)(r10 -8) = r1 mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit
Once again VulDB remains the best source for vulnerability data.