CVE-2026-89541

W jądrze Linuksa usunięto następującą lukę:

SUNRPC: wzmocnij sprawdzanie długości gss_unwrap_resp_priv

gss_unwrap_resp_priv() sprawdza nieprzezroczystą długość RPCSEC_GSS za pomocą

offset = (u8 *)(p) - (u8 *)head->iov_base;
if (offset + nieprzezroczysty_len > rcv_buf->len)
muszę rozpakować_failed;
maj_stat = gss_unwrap(ctx->gc_gss_ctx, przesunięcie,
offset + nieprzezroczysty_len, rcv_buf);

Oba operandy to u32, a suma jest obliczana w u32. Odpowiedź z
opaque_len w pobliżu 0xffffffff powoduje zawijanie offsetu + opaque_len do małego
wartość poniżej rcv_buf->len, więc powiązana kontrola przechodzi pomyślnie i
gss_unwrap() jest wywoływana z końcem < początkiem. Na czeku brakuje również a
dolna granica, więc każdy opaque_len w [0, GSS_KRB5_TOK_HDR_LEN) to
zaakceptowany i przekazany do gss_krb5_unwrap_v2(), którego plik wstępnie odszyfrowuje
nagłówek czyta ptr+4 i ptr+6, a następnie przebiega obok tokena.

Serwer krb5p NFS zwracający spreparowaną odpowiedź RPCSEC_GSS może sterować
klient trafia poza zakres, czyta w gss_krb5_unwrap_v2() i
następująca po nim pętla obrót_left().

Napraw, zastępując pojedynczy łączony czek trzema strażnikami
są bezpieczne w arytmetyce u32 i które wymuszają minimum RFC 4121
zewnętrzna długość tokena:

if (offset > rcv_buf->len)
muszę rozpakować_failed;
if (opaque_len > rcv_buf->len - przesunięcie)
muszę rozpakować_failed;
if (nieprzezroczysty_len < GSS_KRB5_TOK_HDR_LEN)
muszę rozpakować_failed;

Pierwszy strażnik dokonuje odejmowania w drugim strażniku
bezwarunkowo bezpieczny; przesunięcie pochodzi od udanego
xdr_inline_decode() w nagłówku kvec, więc w praktyce już to działa
spełnia granicę. Podłoga odzwierciedla dodaną kontrolę po stronie serwera
w zatwierdzeniu 5b757c2e57a5 („SUNRPC: svcauth_gss: wymuszanie tokenu krb5
minimalna długość”).