Durante la fase de desarrollo de Linux 7.4, Linus Torvalds ha tomado la decisión de retirar de manera definitiva las funciones __get_user() y __put_user() de la arquitectura x86. Esta modificación, registrada de forma oficial en el repositorio Git del proyecto, cierra de raíz una vulnerabilidad de diseño que el sistema operativo arrastraba desde sus primeros años. Las rutinas eliminadas se empleaban habitualmente para la transferencia rápida de variables entre el espacio de usuario y el espacio del núcleo, pero carecían de los mecanismos mínimos para verificar si los rangos de memoria solicitados eran seguros o si la dirección pertenecía legítimamente al proceso que realizaba la llamada.
El movimiento implica una reestructuración profunda en el acceso a memoria por parte del kernel. Para acelerar la sustitución de estas llamadas dispersas en cientos de archivos del sistema, Torvalds se ha apoyado en herramientas de inteligencia artificial para llevar a cabo la migración hacia las nuevas interfaces desarrolladas por la comunidad.
-¿Por qué las variantes con doble guion bajo se convirtieron en un vector de ataque?
Para comprender el riesgo latente, conviene analizar la división fundamental de la memoria dentro del sistema operativo. Linux separa estrictamente el espacio de usuario —donde se ejecutan las aplicaciones convencionales— del espacio del kernel, una zona con privilegios elevados que interactúa con el hardware. Cada vez que un programa requiere enviar o recibir datos desde el núcleo, el sistema debe efectuar una copia controlada de las variables.
Las funciones estándar get_user() y put_user() ejecutan dicha copia tras validar exhaustivamente que la dirección de origen o destino pertenece al rango autorizado. Por el contrario, las variantes obsoletas __get_user() y __put_user() omitían por completo esta comprobación previa, asumiendo que el programador había verificado manualmente los límites con anterioridad. El propio Torvalds ha fundamentado la necesidad de erradicar este mecanismo en el mensaje del commit principal:
«Esto era algo que hacía mucha falta. Y cuando se usan mal, es decir, prácticamente en todos los casos, no solo son más lentas que la alternativa adecuada, sino también inseguras porque no comprueban el rango de direcciones del usuario.»
-El avance de los procesadores modernos anuló las ventajas de rendimiento originales
La razón por la que estas rutinas permanecieron activas durante décadas radica en los criterios de optimización de los procesadores antiguos. Años atrás, verificar los rangos de memoria suponía un impacto medible en los ciclos de CPU, por lo que los desarrolladores realizaban una única validación manual al inicio de un bloque y luego ejecutaban múltiples llamadas rápidas sin comprobación.
Sin embargo, la arquitectura del hardware actual ha cambiado esta dinámica. En los procesadores modernos, la penalización sobre el rendimiento ya no proviene de la validación del rango numérico, sino del proceso de conmutación de los estados de protección del procesador cada vez que el núcleo abre y cierra la ventana de acceso a la memoria del usuario. Mantener las funciones inseguras no aportaba las ganancias de velocidad prometidas y solo incrementaba la superficie de ataque del núcleo.
Para resolver este cuello de botella sin comprometer la seguridad, el desarrollador veterano Thomas Gleixner diseñó un conjunto de interfaces de acceso con ámbito (scoped access). Este nuevo paradigma permite al kernel abrir la ventana de protección de memoria una sola vez para agrupar múltiples lecturas o escrituras en un mismo bloque, cerrando el acceso únicamente al finalizar la transacción global.
-El uso de Claude Code para la migración masiva y el impacto en las distintas arquitecturas
Sustituir cada llamada obsoleta distribuida por el árbol de código del kernel representaba un trabajo mecánico colosal. Para agilizar el proceso, Torvalds admitió haber utilizado la herramienta de inteligencia artificial Claude Code, delegando en este asistente la localización de las rutinas afectadas y su reemplazo por las nuevas interfaces seguras de Gleixner. Torvalds revisó minuciosamente el código modificado antes de fusionarlo con la rama principal, garantizando que el criterio técnico se mantuviera bajo su supervisión directa en uno de los primeros hitos de refactorización masiva asistida por IA dentro del proyecto.
El impacto de esta decisión varía según la arquitectura de hardware empleada:
- Arquitectura ARM64: En plataformas de 64 bits de ARM, las funciones
__get_user()y__put_user()ya estaban vinculadas internamente a las versiones seguras, por lo que nunca presentaron el déficit de validación existente en x86. - Entornos de desarrollo x86: Los programadores que mantengan módulos o controladores para la arquitectura x86 deberán adaptar sus proyectos para emplear las nuevas interfaces orientadas a bloques, dado que las llamadas antiguas han sido eliminadas por completo del código genérico.
- Usuarios finales: Para quienes utilizan distribuciones de Linux en equipos personales o servidores, la transición resulta completamente transparente en términos de configuración, aportando como beneficio directo un núcleo más robusto frente a potenciales fallos de elevación de privilegios.