Descripción
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: reforzar las verificaciones de longitud de gss_unwrap_resp_priv gss_unwrap_resp_priv() valida la longitud opaca de RPCSEC_GSS con offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Ambos operandos son u32 y la suma se calcula en u32. Una respuesta con opaque_len cercano a 0xffffffff hace que offset + opaque_len dé la vuelta a un valor pequeño inferior a rcv_buf->len, por lo que la verificación de límite se supera y se llama a gss_unwrap() con end < begin. La verificación además carece de un límite inferior, por lo que cualquier opaque_len en [0, GSS_KRB5_TOK_HDR_LEN) se acepta y se reenvía a gss_krb5_unwrap_v2(), cuyas lecturas del encabezado previas al descifrado en ptr+4 y ptr+6 van entonces más allá del token. Un servidor NFS con krb5p que devuelva una respuesta RPCSEC_GSS especialmente manipulada puede llevar al cliente a realizar lecturas fuera de límites en gss_krb5_unwrap_v2() y en el bucle rotate_left() que le sigue. Se corrige reemplazando la verificación combinada única por tres protecciones que son seguras en aritmética u32 y que exigen la longitud mínima del token externo según RFC 4121: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; La primera protección hace que la resta de la segunda sea siempre segura; offset se deriva de un xdr_inline_decode() exitoso en el kvec head, por lo que en la práctica ya cumple el límite. El mínimo replica la verificación del lado del servidor agregada en el commit 5b757c2e57a5 ("SUNRPC: svcauth_gss: enforce krb5 token minimum length").
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf y anteriores a 3691c4b3488d8ca046b9941e5be30c626dbbbb50 · 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf y anteriores a 85fa6b12e8f439739ac36ef2aad925f37c8b976a · 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf y anteriores a 401f6a5b338d05bb1069ad814d9f77e3c367854f · 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf y anteriores a 81fd7654a8429718adfcb2a7e03496077f547ed0 · 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf y anteriores a 89a15a50f84d32d4b99db86f957427fcbe20a99a · 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf y anteriores a ebcbd2523a8524c3d24e111cdbed8e271d910269 · 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf y anteriores a d395c30d570ca6168f0297b191709927d1258273 · 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf y anteriores a 87831b92112c81db251d46756d65daa4f91af6a2
- Linux Afectadas: 2.6.15 No afectadas: 5.10.270 · 5.15.221 · 6.1.188 · 6.6.157 · 6.12.109 · 6.18.50
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/3691c4b3488d8ca046b9941e5be30c626dbbbb50
- Referencia en git.kernel.orggit.kernel.org/stable/c/85fa6b12e8f439739ac36ef2aad925f37c8b976a
- Referencia en git.kernel.orggit.kernel.org/stable/c/401f6a5b338d05bb1069ad814d9f77e3c367854f
- Referencia en git.kernel.orggit.kernel.org/stable/c/81fd7654a8429718adfcb2a7e03496077f547ed0
- Referencia en git.kernel.orggit.kernel.org/stable/c/89a15a50f84d32d4b99db86f957427fcbe20a99a
- Referencia en git.kernel.orggit.kernel.org/stable/c/ebcbd2523a8524c3d24e111cdbed8e271d910269
- Referencia en git.kernel.orggit.kernel.org/stable/c/d395c30d570ca6168f0297b191709927d1258273
- Referencia en git.kernel.orggit.kernel.org/stable/c/87831b92112c81db251d46756d65daa4f91af6a2
Ver el texto original en inglés (CVE.org)
SUNRPC: harden gss_unwrap_resp_priv length checks
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 ("SUNRPC: svcauth_gss: enforce krb5 token minimum length").