El nucli de Linux ha bufat 35 espelmes des d'aquell missatge que Linus Torvalds va enviar a un fòrum d'Usenet el 25 d'agost de 1991. El que va començar com un entreteniment d'estudiant a la Universitat d'Hèlsinki, cansat de les limitacions de MINIX, s'ha convertit en una peça que sosté el 70% i bona part d?internet i el núvol públic. La versió 7.2 s'acaba de publicar i el codi del projecte supera ja els 40 milions de línies, de les quals al voltant de 30 milions corresponen a codi real.
Darrere aquesta escala hi ha una decisió més jurídica que tècnica. En els seus primers temps, Torvalds va fer servir una llicència pròpia que impedia la redistribució comercial, cosa que tallava qualsevol negoci sostenible. Al començament de 1992 va adoptar la GPLv2 , efectiva des de l'1 de febrer, i la versió 0.95 va ser la primera distribuïda sota aquests termes. Aquesta fórmula permetia fer servir, modificar i redistribuir el codi, sempre que les modificacions es publiquessin amb la mateixa llicència. Així van néixer empreses com Red Hat i SUSE, i el mateix Torvalds va resumir després que fer que Linux fos GPL va ser, amb diferència, el millor que havia fet. El nucli continua sent GPL-2.0-only: el 2007 va rebutjar migrar la GPLv3 per la seva clàusula contra la tivoització.
Un projecte que va començar amb molt poc i va arribar molt lluny
El primer codi, la versió 0.01, va aparèixer el 17 de setembre de 1991 amb només 10.239 línies i ni tan sols podia executar-se per si mateix: necessitava el MINIX per compilar-se. La 0.02 va arribar el 5 d'octubre i es considera la primera «oficial», mentre que al desembre la 0.11 va fer el salt definitiu en poder compilar-se a si mateixa corrent sobre Linux. La comunitat va respondre ràpid: el 1993 ja hi havia més d'un centenar de desenvolupadors i van néixer dues distribucions que segueixen vives, Slackware i Debian.
No tothom ho va veure clar. El 29 de gener de 1992, Andrew Tanenbaum va publicar un missatge titulat «LINUX està obsolet», on defensava que els kernels monolítics eren un disseny dels anys 70 davant dels microkernels i que un sistema lligat a l'Intel 386 mai no arribaria a altres arquitectures. Els fets van treure la raó a Tanenbaum en ambdós fronts: la versió 1.2, de març de 1995, va afegir suport per a Alpha, SPARC i MIPS , i des de llavors el nucli s'ha portat a desenes d'arquitectures.
Torvalds es cansa dels pegats trivials creats amb IA
Que Linus Torvalds segueix actiu no és cap novetat, encara que ell mateix reconegui que ja no aporta tantes línies de codi com abans. El que ha canviat és el malestar amb l'ús desmesurat d'eines d'intel·ligència artificial per localitzar i reparar errors. No s'oposa a la IA com a suport, però sí que s'utilitzi malament. A la versió 7.1 del nucli , en plena cinquena Release Candidate de les set habituals, ha vist un excés de resolucions de bugs insignificants que consumeixen temps i recursos.
Segons va explicar als col·laboradors, molts d'aquests arranjaments arriben en instàncies inadequades. La majoria de les correccions incorporades a la RC5 s'haurien d'haver proposat en etapes inicials del projecte. Torvalds va dir que aquesta RC5 era força gran en comparació amb versions prèvies a la mateixa fase i que no estava del tot content: la major part eren coses trivials de controladors comuns. La idea és que aquest tipus de retocs s'incloguin en un arbre de Linux-next i s'unifiquin durant el període de fusió, no en una fase avançada.
El problema no només és que els pegats siguin menors, sinó que estan provocant un coll d'ampolla. S'han detectat casos de diverses persones que troben i resolen les mateixes fallades, però les notifiquen per separat. Aquesta superposició de pegats resulta confusa i ineficient per als veritables mantenidors. Torvalds ha avisat que serà més inflexible i que començarà a rebutjar pull requests sense sentit amb correccions poc importants.
També hi ha un risc tècnic. Usar agents d'IA per resoldre un bug pot generar de manera inadvertida una fallada nova, cosa que afegeix més feina i fins i tot pot obrir una vulnerabilitat més greu que l'original. Torvalds ho va resumir amb una idea senzilla: les correccions trivials poden ser insignificants i tenir una baixa probabilitat de causar problemes, però “baixa probabilitat” no és el mateix que probabilitat nul·la . Si algú vol col·laborar amb el nucli, millor que eviti la IA per a fallades menors en fases avançades.
Els contenidors ja no són una gàbia segura
L'empresa de seguretat Depthfirst ha publicat una anàlisi en què sosté que els contenidors a l'estil Docker o Kubernetes han deixat de ser una barrera de seguretat prou sòlida. La tesi és que cal partir de la base que un atacant sabrà sortir d'un contenidor quan vulgui, sense gaire dificultat. Un contenidor fa la impressió de ser una màquina pròpia, però no inclou un sistema operatiu complet: tots els contenidors d'un servidor passen pel mateix nucli Linux del host , que gestiona memòria, processador i xarxa.
Molts organitzadors de CTF i altres entorns es fien a cegues i allotgen diverses proves al mateix servidor, cadascuna al seu contenidor, confiant només en la seguretat del host. És una falsa sensació de protecció. Com a prova, Depthfirst esmenta un butlletí d'AWS datat el novembre de 2025 en què l'empresa ja no considera els contenidors com una barrera de seguretat i, per tant, no els fa servir per aïllar clients entre si.
El que ha canviat els últims mesos és el preu d'entrada per cercar errors. Amb models d'IA d'avantguarda, un atacant amb mitjans modestos pot fabricar un exploit contra màquines encara no pegats quan es publica una fallada, cosa que abans requeria coneixements seriosos. Les xifres de Depthfirst mostren l'acceleració: al gener es van publicar 249 CVE per al nucli de Linux ia l'agost en van ser 1.650 . De les 36 CVE divulgades a través del kernelCTF de Google, 13 es poden explotar mitjançant interfícies ordinàries, com ara els sockets locals que un contenidor rep per defecte.
El passat 24 de juliol, Depthfirst va aconseguir un lloc al kernelCTF amb un exploit 0day, abans de qualsevol pegat, i avui el PoC està disponible a GitHub. Al nucli de Linux el pegat va sortir el 6 d'agost, però a Ubuntu l'actualització a data del 24 de setembre encara mostrava el nucli de la 26.04 com a «Vulnerable, work in progress» i el de la 24.04 com a «Vulnerable» . Trobar vulnerabilitats s'ha tornat ràpid; corregir-les a totes les releases i màquines porta temps.
Com protegir-se? Depthfirst proposa directament deixar de compartir el nucli i migrar les càrregues no fiables a microVM, màquines virtuals lleugeres on cada càrrega té el seu propi nucli. Aquí entren projectes com Firecracker i Kata Containers. Si un atacant trenca un d'aquests kernels, en teoria només compromet la seva pròpia instància i no el host sencer. Això sí, Firecracker es recolza en KVM, el component de virtualització del nucli Linux del host, i KVM també ha tingut errors. El Januscape permetia escapar de la màquina física si el host permetia virtualització imbricada. La superfície datac és menor, però no nul·la. Mentrestant, a Ubuntu 24/04 o 26/04 convé vigilar l'arribada del proper nucli; Canonical ha anunciat una publicació setmanal de kernels per intentar compensar aquest ritme.
Spectre v2 reapareix amb Branch Target Reuse
VUSec ha descrit Branch Target Reuse (BTR), un atac Spectre v2 que va aprofitar el compilador JIT de cBPF a Linux per recuperar el hash d'una contrasenya de root. El grup també informa que els desenvolupadors del nucli van incorporar una mitigació x86 per fer front a la reutilització de regions de codi. BTR explota prediccions de salts indirectes que poden persistir després que s'alliberi codi generat per un compilador JIT i un altre bloc reutilitzi la vostra adreça. La CPU pot llavors especular cap a una posició obsoleta dins del nou codi.
VUSec descriu dos exploits complets d'extrem a extrem contra el compilador JIT de cBPF a Linux: un amb la configuració predeterminada i un altre que va funcionar amb l'ofuscació de constants activada. La demostració va recuperar un hash de contrasenya de root de la memòria d'un procés seu. Convé recordar que un hash no és la contrasenya en text pla: per obtenir-la cal intentar trencar-lo, i les possibilitats depenen de l'algorisme i de la fortalesa de la contrasenya. VUSec xifra la filtració en vuit bytes per segon i explica que el seguiment de punters redueix la quantitat de dades que cal extreure per arribar al secret.
Els processadors prediuen la destinació dels salts indirectes per executar instruccions per avançat. BTR aprofita que aquesta predicció pot quedar desfasada respecte al codi que ara ocupa una adreça de memòria. A la demostració de Linux, els programes cBPF s'instal·len com a filtres seccomp. La tècnica va funcionar amb programes clàssics BPF disponibles per a processos sense privilegis; VUSec distingeix aquest cas d'eBPF, el JIT del qual, segons el grup, està restringit a usuaris privilegiats. Els resultats no van ser iguals a tots els motors: a Linux cBPF hi va haver dos exploits complets; a Firefox SpiderMonkey es va obtenir una prova de concepte amb prediccions obsoletes després de reutilitzar codi, però no un exploit complet del navegador; a Oracle GraalVM no van completar un atac perquè la compilació interna i la recol·lecció d'escombraries van esborrar les entrades de predicció. Oracle mitiga la reutilització aleatoritzant les ubicacions de la memòria cau de codi JIT. Les mitjanes comunicades van ser de tres minuts a Raptor Cove i cinc minuts a Lion Cove.
La mitigació incorporada al nucli emet una barrera IBPB, que neteja el predictor de salts indirectes, a tots els nuclis quan un programa cBPF reutilitza una regió executada prèviament de cBPF o eBPF. La mesura també desincentiva aquesta reutilització. VUSec relaciona els identificadors CVE-2026-64507 i CVE-2026-64508 amb els problemes de Linux i recomana instal·lar les actualitzacions del sistema operatiu i del programari quan els proveïdors publiquin els pegats. El grup afirma que va observar el comportament a totes les CPU que va provar d'Intel, AMD i Arm, encara que la demostració de recuperació del hash es va realitzar en processadors Intel Raptor Cove i Lion Cove. L'article de recerca sobre BTR va ser acceptat per a ACM CCS 2026 i tenia prevista la seva publicació al novembre del 2026.
Què mirar si administres equips Linux
Tot i que l'aniversari i l'evolució del nucli conviden a celebrar, la part pràctica continua exigint feina. En entorns d'empresa i administració pública, sobretot a Espanya i la resta d'Europa, cal no donar per fet que un contenidor aïlla prou. Si s'executen càrregues no fiables, té més sentit fer servir microVM amb kernel propi, revisar els pegats del host i no barrejar serveis crítics al mateix servidor sense capes addicionals.
També cal vigilar de prop el cicle d'actualitzacions. La publicació setmanal de kernels de Canonical ajuda, però no eximeix de comprovar si una versió concreta d'Ubuntu segueix marcada com a vulnerable. En el desenvolupament, la IA pot ser útil per a tasques pesades, tot i que Torvalds ha deixat clar que no vol que es converteixi en una fàbrica de pegats menors en moments delicats. La seguretat del nucli depèn de revisar, prioritzar i pegats amb criteri, no acumular canvis perquè una eina els generi amb facilitat.
El kernel Linux arriba al 35è aniversari amb una escala enorme, més de 40 milions de línies i presència en superordinadors, mòbils i núvol. Alhora, afronta un debat intern sobre l'ús de la IA en el desenvolupament, atacs com BTR que exploten el maquinari i un problema de fons amb els contenidors: comparteixen nucli i ja no són suficients com a única defensa. La història del programari lliure continua sent sòlida, però mantenir-la exigeix pegats a temps, aïllament més fort i decisions tècniques sense dreceres.
