El kernel de Linux ha soplado 35 velas desde aquel mensaje que Linus Torvalds enviĆ³ a un foro de Usenet el 25 de agosto de 1991. Lo que empezĆ³ como un entretenimiento de estudiante en la Universidad de Helsinki, cansado de las limitaciones de MINIX, se ha convertido en una pieza que sostiene el cien por cien de los superordenadores, cerca del 70% de los mĆ³viles mediante Android y buena parte de internet y la nube pĆŗblica. La versiĆ³n 7.2 acaba de publicarse y el cĆ³digo del proyecto supera ya los 40 millones de lĆneas, de las que alrededor de 30 millones corresponden a cĆ³digo real.
DetrĆ”s de esa escala hay una decisiĆ³n mĆ”s jurĆdica que tĆ©cnica. En sus primeros tiempos, Torvalds usĆ³ una licencia propia que impedĆa la redistribuciĆ³n comercial, lo que cortaba cualquier negocio sostenible. A comienzos de 1992 adoptĆ³ la GPLv2, efectiva desde el 1 de febrero, y la versiĆ³n 0.95 fue la primera distribuida bajo esos tĆ©rminos. Esa fĆ³rmula permitĆa usar, modificar y redistribuir el cĆ³digo, siempre que las modificaciones se publicasen con la misma licencia. AsĆ nacieron empresas como Red Hat y SUSE, y el propio Torvalds resumiĆ³ despuĆ©s que hacer que Linux fuera GPL fue, con diferencia, lo mejor que habĆa hecho. El nĆŗcleo sigue siendo GPL-2.0-only: en 2007 rechazĆ³ migrar a la GPLv3 por su clĆ”usula contra la tivoizaciĆ³n.
Un proyecto que empezĆ³ con muy poco y llegĆ³ muy lejos
El primer cĆ³digo, la versiĆ³n 0.01, apareciĆ³ el 17 de septiembre de 1991 con apenas 10.239 lĆneas y ni siquiera podĆa ejecutarse por sĆ solo: necesitaba MINIX para compilarse. La 0.02 llegĆ³ el 5 de octubre y se considera la primera Ā«oficialĀ», mientras que en diciembre la 0.11 dio el salto definitivo al poder compilarse a sĆ misma corriendo sobre Linux. La comunidad respondiĆ³ rĆ”pido: en 1993 ya habĆa mĆ”s de un centenar de desarrolladores y nacieron dos distribuciones que siguen vivas, Slackware y Debian.
No todo el mundo lo vio claro. El 29 de enero de 1992, Andrew Tanenbaum publicĆ³ un mensaje titulado Ā«LINUX estĆ” obsoletoĀ», donde defendĆa que los kernels monolĆticos eran un diseƱo de los aƱos 70 frente a los microkernels y que un sistema atado al Intel 386 nunca llegarĆa a otras arquitecturas. Los hechos le quitaron la razĆ³n a Tanenbaum en ambos frentes: la versiĆ³n 1.2, de marzo de 1995, aƱadiĆ³ soporte para Alpha, SPARC y MIPS, y desde entonces el kernel se ha portado a decenas de arquitecturas.
Torvalds se cansa de los parches triviales creados con IA
Que Linus Torvalds sigue activo no es ninguna novedad, aunque Ć©l mismo reconozca que ya no aporta tantas lĆneas de cĆ³digo como antes. Lo que ha cambiado es su malestar con el uso desmedido de herramientas de inteligencia artificial para localizar y reparar fallos. No se opone a la IA como apoyo, pero sĆ a que se use mal. En la versiĆ³n 7.1 del kernel, en plena quinta Release Candidate de las siete habituales, ha visto un exceso de resoluciones de bugs insignificantes que consumen tiempo y recursos.
SegĆŗn explicĆ³ a los colaboradores, muchos de esos arreglos llegan en instancias inapropiadas. La mayorĆa de las correcciones incorporadas en la RC5 deberĆan haberse propuesto en etapas iniciales del proyecto. Torvalds dijo que esa RC5 era bastante grande en comparaciĆ³n con versiones previas en la misma fase y que no estaba del todo contento: la mayor parte eran cosas triviales de controladores comunes. Su idea es que ese tipo de retoques se incluyan en un Ć”rbol de Linux-next y se unifiquen durante el periodo de fusiĆ³n, no en una fase avanzada.
El problema no es solo que los parches sean menores, sino que estĆ”n provocando un cuello de botella. Se han detectado casos de varias personas que encuentran y resuelven los mismos fallos, pero los notifican por separado. Esa superposiciĆ³n de parches resulta confusa e ineficiente para los verdaderos mantenedores. Torvalds ha avisado de que serĆ” mĆ”s inflexible y que empezarĆ” a rechazar pull requests sin sentido con correcciones poco importantes.
TambiĆ©n hay un riesgo tĆ©cnico. Usar agentes de IA para resolver un bug puede generar de forma inadvertida un fallo nuevo, lo que aƱade mĆ”s trabajo e incluso puede abrir una vulnerabilidad mĆ”s grave que la original. Torvalds lo resumiĆ³ con una idea sencilla: las correcciones triviales pueden ser insignificantes y tener una baja probabilidad de causar problemas, pero Ā«baja probabilidadĀ» no es lo mismo que probabilidad nula. Si alguien quiere colaborar con el kernel, mejor que evite la IA para fallos menores en fases avanzadas.
Los contenedores ya no son una jaula segura
La empresa de seguridad Depthfirst ha publicado un anĆ”lisis en el que sostiene que los contenedores al estilo Docker o Kubernetes han dejado de ser una barrera de seguridad lo bastante sĆ³lida. La tesis es que hay que partir de la base de que un atacante sabrĆ” salir de un contenedor cuando quiera, sin demasiada dificultad. Un contenedor da la impresiĆ³n de ser una mĆ”quina propia, pero no incluye un sistema operativo completo: todos los contenedores de un servidor pasan por el mismo kernel Linux del host, que gestiona memoria, procesador y red.
Muchos organizadores de CTF y otros entornos se fĆan a ciegas y alojan varias pruebas en el mismo servidor, cada una en su contenedor, confiando solo en la seguridad del host. Es una falsa sensaciĆ³n de protecciĆ³n. Como prueba, Depthfirst menciona un boletĆn de AWS fechado en noviembre de 2025 en el que la empresa ya no considera los contenedores como una barrera de seguridad y, por tanto, no los usa para aislar clientes entre sĆ.
Lo que ha cambiado en los Ćŗltimos meses es el precio de entrada para buscar fallos. Con modelos de IA de vanguardia, un atacante con medios modestos puede fabricar un exploit contra mĆ”quinas aĆŗn no parcheadas en cuanto se publica un fallo, algo que antes requerĆa conocimientos serios. Las cifras de Depthfirst muestran la aceleraciĆ³n: en enero se publicaron 249 CVE para el kernel de Linux y en agosto fueron 1.650. De las 36 CVE divulgadas a travĆ©s del kernelCTF de Google, 13 se pueden explotar mediante interfaces ordinarias, como los sockets locales que un contenedor recibe por defecto.
El pasado 24 de julio, Depthfirst consiguiĆ³ un puesto en el kernelCTF con un exploit 0day, antes de cualquier parche, y hoy el PoC estĆ” disponible en GitHub. En el kernel de Linux el parche saliĆ³ el 6 de agosto, pero en Ubuntu la actualizaciĆ³n a fecha del 24 de septiembre aĆŗn mostraba el kernel de la 26.04 como Ā«Vulnerable, work in progressĀ» y el de la 24.04 como Ā«VulnerableĀ». Encontrar vulnerabilidades se ha vuelto rĆ”pido; corregirlas en todas las releases y mĆ”quinas lleva tiempo.
ĀæCĆ³mo protegerse? Depthfirst propone directamente dejar de compartir el kernel y migrar las cargas no fiables a microVM, mĆ”quinas virtuales ligeras donde cada carga tiene su propio kernel. AhĆ entran proyectos como Firecracker y Kata Containers. Si un atacante rompe uno de esos kernels, en teorĆa solo compromete su propia instancia y no el host entero. Eso sĆ, Firecracker se apoya en KVM, el componente de virtualizaciĆ³n del kernel Linux del host, y KVM tambiĆ©n ha tenido fallos. El Januscape permitĆa escapar de la mĆ”quina fĆsica si el host permitĆa virtualizaciĆ³n anidada. La superficie de ataque es menor, pero no nula. Mientras tanto, en Ubuntu 24.04 o 26.04 conviene vigilar la llegada del prĆ³ximo kernel; Canonical ha anunciado una publicaciĆ³n semanal de kernels para intentar compensar este ritmo.
Spectre v2 reaparece con Branch Target Reuse
VUSec ha descrito Branch Target Reuse (BTR), un ataque Spectre v2 que aprovechĆ³ el compilador JIT de cBPF en Linux para recuperar el hash de una contraseƱa de root. El grupo tambiĆ©n informa de que los desarrolladores del kernel incorporaron una mitigaciĆ³n x86 para hacer frente a la reutilizaciĆ³n de regiones de cĆ³digo. BTR explota predicciones de saltos indirectos que pueden persistir despuĆ©s de que se libere cĆ³digo generado por un compilador JIT y otro bloque reutilice su direcciĆ³n. La CPU puede entonces especular hacia una posiciĆ³n obsoleta dentro del cĆ³digo nuevo.
VUSec describe dos exploits completos de extremo a extremo contra el compilador JIT de cBPF en Linux: uno con la configuraciĆ³n predeterminada y otro que funcionĆ³ con la ofuscaciĆ³n de constantes activada. La demostraciĆ³n recuperĆ³ un hash de contraseƱa de root de la memoria de un proceso su. Conviene recordar que un hash no es la contraseƱa en texto plano: para obtenerla habrĆa que intentar romperlo, y las posibilidades dependen del algoritmo y de la fortaleza de la contraseƱa. VUSec cifra la filtraciĆ³n en ocho bytes por segundo y explica que el seguimiento de punteros reduce la cantidad de datos que hay que extraer para llegar al secreto.
Los procesadores predicen el destino de los saltos indirectos para ejecutar instrucciones por adelantado. BTR aprovecha que esa predicciĆ³n puede quedar desfasada respecto al cĆ³digo que ocupa ahora una direcciĆ³n de memoria. En la demostraciĆ³n de Linux, los programas cBPF se instalan como filtros seccomp. La tĆ©cnica funcionĆ³ con programas clĆ”sicos BPF disponibles para procesos sin privilegios; VUSec distingue ese caso de eBPF, cuyo JIT, segĆŗn el grupo, estĆ” restringido a usuarios privilegiados. Los resultados no fueron iguales en todos los motores: en Linux cBPF hubo dos exploits completos; en Firefox SpiderMonkey se obtuvo una prueba de concepto con predicciones obsoletas tras reutilizar cĆ³digo, pero no un exploit completo del navegador; en Oracle GraalVM no completaron un ataque porque la compilaciĆ³n interna y la recolecciĆ³n de basura borraron las entradas de predicciĆ³n. Oracle mitiga la reutilizaciĆ³n aleatorizando las ubicaciones de la cachĆ© de cĆ³digo JIT. Los promedios comunicados fueron de tres minutos en Raptor Cove y cinco minutos en Lion Cove.
La mitigaciĆ³n incorporada al kernel emite una barrera IBPB, que limpia el predictor de saltos indirectos, en todos los nĆŗcleos cuando un programa cBPF reutiliza una regiĆ³n ejecutada previamente de cBPF o eBPF. La medida tambiĆ©n desincentiva esa reutilizaciĆ³n. VUSec relaciona los identificadores CVE-2026-64507 y CVE-2026-64508 con los problemas de Linux y recomienda instalar las actualizaciones del sistema operativo y del software cuando los proveedores publiquen los parches. El grupo afirma que observĆ³ el comportamiento en todas las CPU que probĆ³ de Intel, AMD y Arm, aunque la demostraciĆ³n de recuperaciĆ³n del hash se realizĆ³ en procesadores Intel Raptor Cove y Lion Cove. El artĆculo de investigaciĆ³n sobre BTR fue aceptado para ACM CCS 2026 y tenĆa prevista su publicaciĆ³n en noviembre de 2026.
QuƩ mirar si administras equipos Linux
Aunque el aniversario y la evoluciĆ³n del kernel inviten a celebrar, la parte prĆ”ctica sigue exigiendo trabajo. En entornos de empresa y administraciĆ³n pĆŗblica, sobre todo en EspaƱa y el resto de Europa, conviene no dar por hecho que un contenedor aĆsla lo suficiente. Si se ejecutan cargas no confiables, tiene mĆ”s sentido usar microVM con kernel propio, revisar los parches del host y no mezclar servicios crĆticos en el mismo servidor sin capas adicionales.
TambiĆ©n toca vigilar de cerca el ciclo de actualizaciones. La publicaciĆ³n semanal de kernels de Canonical ayuda, pero no exime de comprobar si una versiĆ³n concreta de Ubuntu sigue marcada como vulnerable. En el desarrollo, la IA puede ser Ćŗtil para tareas pesadas, aunque Torvalds ha dejado claro que no quiere que se convierta en una fĆ”brica de parches menores en momentos delicados. La seguridad del kernel depende de revisar, priorizar y parchear con criterio, no de acumular cambios porque una herramienta los genere con facilidad.
El kernel Linux llega a su 35Āŗ aniversario con una escala enorme, mĆ”s de 40 millones de lĆneas y presencia en superordenadores, mĆ³viles y nube. Al mismo tiempo, afronta un debate interno sobre el uso de la IA en el desarrollo, ataques como BTR que explotan el hardware y un problema de fondo con los contenedores: comparten kernel y ya no bastan como Ćŗnica defensa. La historia del software libre sigue siendo sĆ³lida, pero mantenerla exige parches a tiempo, aislamiento mĆ”s fuerte y decisiones tĆ©cnicas sin atajos.
