Linux ha corregido un acceso fuera de límites al analizar certificados que podía activarse con un usuario sin privilegios. El fallo aparecía al procesar certificados con las extensiones Basic Constraints o Key Usage vacías, porque el primer byte se leía antes de comprobar la longitud. El problema podía dispararse mediante la API keyrings(7) con un certificado специально crafted, según el informe de Leo Lin.
La parte delicada no es solo la lectura fuera de rango. También importa quién podía llegar hasta ella: un usuario sin privilegios. Eso cambia el perfil del fallo, porque no exige una cuenta con permisos elevados para tocar esa ruta del kernel. Leo Lin mostró una prueba de concepto y la divulgación se hizo de forma responsable y fuera de lista.
Un certificado manipulado podía llevar el fallo al kernel sin privilegios
La cadena técnica es bastante concreta. Primero, el kernel parseaba un certificado. Después, en ciertas extensiones vacías, accedía al primer byte antes de validar la longitud disponible. Ese orden es el que abre la puerta al acceso fuera de límites, una clase de error que suele exigir una revisión minuciosa del código de análisis y validación de entradas.
El punto crítico está en la superficie de entrada: la API keyrings(7). Según la fuente, bastaba con entregar al kernel un certificado especialmente preparado para reproducir el problema. Que el desencadenante esté en una interfaz pensada para gestionar claves y certificados hace que el fallo merezca atención, porque conecta una operación aparentemente rutinaria con un error de memoria en una ruta central del sistema.
Por qué este Linux acceso usuarios importa en el kernel
En kernel land, un acceso fuera de límites nunca se mira como un fallo menor. Incluso cuando la fuente no entra en detalles sobre impacto adicional, el simple hecho de que pueda activarse sin privilegios ya obliga a fijarse en la corrección. La validación de certificados es una tarea sensible, y este tipo de errores suele aparecer cuando se asume que una estructura tiene datos que luego no están ahí.
La mención a Basic Constraints y Key Usage también acota bien el alcance. No hablamos de cualquier certificado, sino de casos concretos con extensiones vacías. Eso ayuda a entender por qué la revisión debe centrarse en el orden de lectura y comprobación, no en una parte genérica del subsistema. En paralelo, el uso de una prueba de concepto confirma que el escenario no era teórico.
Qué cambia tras el aviso de Leo Lin y la corrección aplicada
La fuente no detalla qué versión del kernel incorpora el arreglo ni si afecta a ramas mantenidas de forma específica. Sí deja claro que el bug ya está fijado. Para quien sigue la evolución del núcleo, esto encaja con una línea de trabajo constante: ir cerrando pequeños errores de parsing que pueden tener consecuencias desproporcionadas cuando llegan desde entradas controladas por el usuario.
Desde HardwarePremium ya hemos visto cómo el kernel sigue ajustando piezas en frentes muy distintos, desde cambios de compatibilidad como la retirada de soporte para i486 hasta ajustes internos como el requisito mínimo de Rust o el trabajo sobre AMDGPU y Wine. Este caso va por otra vía: menos visible, pero igual de relevante para la salud del sistema. Un certificado mal formado bastaba para golpear una ruta del kernel; ahora esa lectura fuera de límites queda corregida.
Puedes seguir a HardwarePremium en Facebook, Twitter (X), Instagram, Threads, BlueSky o Youtube. También puedes consultar nuestro canal de Telegram para estar al día con las últimas noticias de tecnología.
FAQ
Se ha corregido un acceso fuera de límites al analizar certificados. El error aparecía al procesar extensiones Basic Constraints o Key Usage vacías, porque se leía el primer byte antes de comprobar la longitud.
Sí. La fuente indica que un usuario sin privilegios podía provocar el fallo enviando un certificado especialmente preparado al kernel mediante la API keyrings(7).
Leo Lin reportó el fallo y mostró una prueba de concepto. La divulgación se hizo de forma responsable y fuera de lista.
No. El texto solo confirma que el bug ya está corregido, pero no especifica la versión exacta del kernel ni las ramas afectadas.
