Odebrany

CVE-2026-90269

opublikowano: 17.09.2026, 19:17

modyfikacja: 17.09.2026, 19: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: Odrzuć pobieranie obciążenia ze wskaźników wymagających zabezpieczenia przed błędami

BPF_LOAD_ACQ nie jest przepisywany przez weryfikatora do obciążenia BPF_PROBE_MEM,
w przeciwieństwie do zwykłego BPF_LDX, więc JIT emituje zwykłe obciążenie bez wyjątku
wpis w tabeli, a błąd powoduje panikę w jądrze, zamiast zostać obsłużony.

Odrzuć typy wskaźników źródłowych, w przypadku których BPF_LDX miałby ten błąd
ochrona stosowana, tj. ta, którą włącza bpf_convert_ctx_accesses().
w BPF_PROBE_MEM: goły PTR_TO_BTF_ID, PTR_TO_BTF_ID | PTR_UNTRUSTED,
PTR_TO_BTF_ID | MEM_ALLOC | PTR_UNTRUSTED i PTR_TO_MEM | MEM_RDONLY |
PTR_NIEZAufany.

Można to osiągnąć m.in. ładując ->mm z zaufanej struktury zadania
daje niezaufany wskaźnik do mm_struct i ma wartość NULL dla jądra
wątek:

[...]
SEC("tp_btf/sched_switch")
int BPF_PROG(demo, bool z wywłaszczeniem, struktura zadanie_struct *prev,
struktura zadanie_struktura *następny)
{
struktura mm_struktura *mm = następny->mm; /* niezaufany */

out_ldx = (__u64)mm->pgd; /* BPF_LDX */
out_acq = obciążenie_nabycia(&mm->pgd); /* BPF_LOAD_ACQ */
zwróć 0;
}
[...]

Obydwa odwołują się do tego samego wskaźnika, ale chroniony jest tylko BPF_LDX
(x86-64 JIT, cele skoku pokazane względem postępu):

[...]
; out_ldx = (__u64)mm->pgd;
17: movq $-10485760,%r10
1e: movq %rsi, %r11
21: addq $184,%r11
28: subq %r10, %r11
2b: movabsq $140737498841088,%r10
35: cmpq %r10, %r11
38: ja 0x3e <-- adres jądra?
3a: xorl %edi, %edi <-- nie: dst = 0, pomiń ładowanie
3c: jmp 0x45
3e: movq 184(%rsi), %rdi <-- tak: ładowanie + wpis rozszerzalny
[...]
; obciążenie_nabycia(&mm->pgd)
53: movq %rsi, %rdi
56: movq 184(%rdi), %rax <-- brak kontroli, brak wpisu rozszerzalnego
[...]

Należy zauważyć, że BPF_PROBE_MEM nie jest widoczny w zrzucie bpftool xlated, ponieważ
bpf_insn_prepare_dump() zapisuje go z powrotem do BPF_MEM.

Wskaźnik PTR_TRUSTED celowo nie znajduje się na liście. Taki ładunek jest
również nie jest konwertowany, ale nie musi tak być, ponieważ wskaźnik jest
gwarantowane działanie na żywo, więc pobieranie z niego obciążenia pozostaje dozwolone.

Kontrola jest bramkowana na BPF_LOAD_ACQ, dzięki czemu można uzyskać atomowe RMW i wydanie sklepu
komunikaty o błędach pozostają niezmienione; pisze (RMW / store-release) do takiego
wskaźniki są już odrzucone gdzie indziej, więc potrzebuje tego tylko ładowanie.

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

bpf: Reject load-acquire from pointers requiring fault protection

A BPF_LOAD_ACQ is not rewritten to a BPF_PROBE_MEM load by the verifier,
unlike a regular BPF_LDX, so the JIT emits a plain load with no exception
table entry and a fault panics the kernel instead of being handled.

Reject the source pointer types that a BPF_LDX would have had that fault
protection applied to, i.e. the ones bpf_convert_ctx_accesses() turns
into BPF_PROBE_MEM: a bare PTR_TO_BTF_ID, PTR_TO_BTF_ID | PTR_UNTRUSTED,
PTR_TO_BTF_ID | MEM_ALLOC | PTR_UNTRUSTED and PTR_TO_MEM | MEM_RDONLY |
PTR_UNTRUSTED.

This is reachable e.g. by loading ->mm out of a trusted task_struct
yields an untrusted pointer to mm_struct, and it is NULL for a kernel
thread:

[...]
SEC("tp_btf/sched_switch")
int BPF_PROG(demo, bool preempt, struct task_struct *prev,
struct task_struct *next)
{
struct mm_struct *mm = next->mm; /* untrusted */

out_ldx = (__u64)mm->pgd; /* BPF_LDX */
out_acq = load_acquire(&mm->pgd); /* BPF_LOAD_ACQ */
return 0;
}
[...]

Both dereference the same pointer, but only the BPF_LDX is protected
(x86-64 JIT, jump targets shown prog-relative):

[...]
; out_ldx = (__u64)mm->pgd;
17: movq $-10485760, %r10
1e: movq %rsi, %r11
21: addq $184, %r11
28: subq %r10, %r11
2b: movabsq $140737498841088, %r10
35: cmpq %r10, %r11
38: ja 0x3e <-- kernel addr?
3a: xorl %edi, %edi <-- no: dst = 0, skip the load
3c: jmp 0x45
3e: movq 184(%rsi), %rdi <-- yes: load + extable entry
[...]
; load_acquire(&mm->pgd)
53: movq %rsi, %rdi
56: movq 184(%rdi), %rax <-- no check, no extable entry
[...]

Note that BPF_PROBE_MEM is not visible in a bpftool xlated dump, as
bpf_insn_prepare_dump() rewrites it back to BPF_MEM.

A PTR_TRUSTED pointer is deliberately not on the list. Such a load is
not converted either, but it does not need to be, since the pointer is
guaranteed live, so load-acquire from it stays allowed.

The check is gated on BPF_LOAD_ACQ so that atomic RMW and store-release
error messages are unchanged; writes (RMW / store-release) to such
pointers are already rejected elsewhere, so only load-acquire needs this.

>_ 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