Odebrany

CVE-2026-98134

opublikowano: 25.09.2026, 13:17

modyfikacja: 25.09.2026, 13: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: check_cond_jmp_op(): poprawnie wywnioskowaj, czy rejestr ma wartość null

Nicholas Carlini zgłosił błąd, gdy weryfikator może błędnie wnioskować
że wskaźnik nie jest pusty. Błąd występuje, gdy są dwa wskaźniki
porównane i jeden z nich ma typ bez flagi PTR_MAYBE_NULL,
ale co pozwala na wartość NULL w czasie wykonywania.
Oto przykład:

// `a` to PTR_TO_MEM | MEM_RDONLY | PTR_NIEZAufany
// `a` wynosi 0 w czasie wykonywania.
// `b` to PTR_TO_MAP_VALUE | PTR_MAYBE_NULL
void *a = bpf_rdonly_cast(0, 0);
int *b = bpf_map_lookup_elem(...);

jeśli (a == b)
*b = 42; // weryfikator nie przechwytuje dereferencji wskaźnika zerowego

Dzieje się tak z powodu specjalnego przypadku w check_cond_jmp_op(),
który próbuje usunąć flagi PTR_MAYBE_NULL z typów wskaźników,
podczas przetwarzania porównań typu `rA == rB`, jeśli rA lub rB nie mogą
być zerowe.

Właściwość różna od null jest wyprowadzana na podstawie braku
Flaga PTR_MAYBE_NULL dla typu rA lub rB. Ale to nie wystarczy
dla typów takich jak PTR_TO_MEM, jak w przykładzie.

Ta poprawka zastępuje wywołanie type_may_be_null() funkcją reg_not_null(),
który zawiera listę dozwolonych typów, dla których brak
PTR_MAYBE_NULL faktycznie oznacza, że wartość nie może mieć wartości NULL w czasie wykonywania.

W tej chwili lista w funkcji reg_not_null() pomija dwa typy for
które mają zastosowanie PTR_MAYBE_NULL: PTR_TO_XDP_SOCK i PTR_TO_BUF.
Aby zachować kompatybilność wsteczną i tylko przy założeniu
porównywanie wskaźników tego samego typu ma sens,
to zatwierdzenie rozszerza funkcję reg_not_null(). Bez takiego rozszerzenia np.
verifier_jeq_infer_not_null/null_ptr_to_map_value kończy się niepowodzeniem.

reg_not_null() można dalej rozszerzyć, ale uważam, że wykracza to poza zakres
dla dostępnej poprawki. Jawny typ_bazowy(...) != PTR_TO_BTF_ID
kontrole w check_cond_jmp_op() można usunąć podczas migracji do
reg_not_null(), ale jest to zmiana w zachowaniu, w szczególnym przypadku
zacznie dopasowywać dla PTR_TO_BTF_ID, czyli również is_trusted_reg().
Pomijam zmianę zachowania w tym zatwierdzeniu.

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

bpf: check_cond_jmp_op(): properly infer if register is null

Nicholas Carlini reported a bug when verifier can incorrectly infer
that a pointer is non-null. The bug occurs when two pointers are
compared and one of them has a type w/o PTR_MAYBE_NULL flag,
but which allows a value to be NULL at runtime.
Here is an example:

// `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED
// `a` is 0 at runtime.
// `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL
void *a = bpf_rdonly_cast(0, 0);
int *b = bpf_map_lookup_elem(...);

if (a == b)
*b = 42; // verifier does not catch null pointer dereference

This happens because of a special case in check_cond_jmp_op(),
which attempts to strip PTR_MAYBE_NULL flags from pointer types,
when processing comparisons like `rA == rB`, if either rA or rB can't
be null.

The non-null property is derived based on the absence of
PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient
for types like PTR_TO_MEM, as in the example.

This patch replaces type_may_be_null() call with reg_not_null(),
which contains an allowlist of types for which absence of
PTR_MAYBE_NULL actually means that the value can't be NULL at runtime.

At the moment, the list in the reg_not_null() omits two types for
which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF.
In order to remain backward compatible, and assuming that only
comparison between pointers of the same type makes sense,
this commit extends reg_not_null(). W/o such an extension e.g.
verifier_jeq_infer_not_null/null_ptr_to_map_value fails.

reg_not_null() can be extended further, but I deem that out of scope
for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID
checks in the check_cond_jmp_op() can be removed with migration to
reg_not_null(), but that is a behavioural change, as the special case
would start matching for PTR_TO_BTF_ID that is also is_trusted_reg().
I omit the behavioural change from this commit.

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