La seguretat de Linux novament enfronta un desafiament després del descobriment de la vulnerabilitat CVE-2026-31431, batejada com a Copy Fail pels investigadors de Xint Code. Lluny de ser una fallada teòrica, aquest problema de disseny permet a un usuari local sense privilegis elevar els seus permisos i obtenir accés total com a superusuari de forma predictible i silenciosa.
Els investigadors esmenten que aquesta fallada ha estat explotada amb èxit en distribucions líders com Ubuntu, Amazon Linux, RHEL i SUSE, confirmant que qualsevol sistema que executi un kernel posterior a la versió 4.14 i mantingui habilitat el suport per a sockets AF_ALG és potencialment vulnerable a aquest atac.
Operacions In-Place i el desbordament del memòria cau de pàgines
Sobre la decisió, s'esmenta que aquesta es remunta a una optimització introduïda el 2017 dins de l'API criptogràfica del nucli (AF_ALG). Aquesta modificació buscava eliminar l'emmagatzematge intermedi innecessari executant operacions de xifratge autenticat (AEAD) directament al mateix espai de memòria, el que es coneix com a operacions «in-place».
El problema crític sorgeix en combinar aquesta optimització amb la funció splice(), la qual transfereix dades entre descriptors de fitxer transferint referències directes a la memòria cau de pàgines del kernel en lloc de copiar físicament les dades. En sol·licitar un desxifrat, l'estructura de memòria es configurava de manera que el memòria intermèdia de destinació, que hauria de ser un espai temporal per a l'usuari, acabava vinculat directament a les pàgines de la memòria cau que contenen les dades dels fitxers del sistema.
Authencesn i l'escriptura fora dels límits de memòria
El detonant final de la vulnerabilitat rau en el comportament anòmal de l'algorisme authencesn. A diferència d'altres rutines criptogràfiques que respecten estrictament els límits dels vostres búfers de destinació, aquest algorisme específic utilitza l'espai de memòria de l'usuari com una àrea de treball temporal (scratch pad) per reorganitzar seqüències de bytes durant el càlcul d'etiquetes d'autenticació.
En aquest procés, l'algorisme escriu quatre bytes més enllà del límit establert per a la regió de sortida. A causa de l'optimització in-place ia la cadena de referències creada per splice(), aquesta escriptura aparentment inofensiva creua la frontera de la memòria de l'usuari i aterra directament a la pàgina de la memòria cau del nucli associada al fitxer que s'està processant.
Aquesta cadena d'errors lògics atorga a l'atacant la capacitat de sobreescriure arbitràriament quatre bytes en posicions específiques de la memòria cau de pàgines per a qualsevol fitxer que pugui llegir. Enviant una sèrie de sol·licituds calculades, un atacant pot injectar codi maliciós a la versió en memòria d'arxius executables crítics amb el bit suid actiu, com l'eina de canvi d'usuari.
Atès que totes les operacions de lectura consulten primer la memòria cau de pàgines, la propera vegada que s'invoqui la utilitat legítima, el sistema executarà el codi injectat des de la memòria, atorgant privilegis de root instantanis sense alterar mai el fitxer físic al disc dur. Més alarmant encara, perquè l'aïllament de contenidors comparteix la memòria cau de pàgines de l'amfitrió subjacent, aquesta vulnerabilitat serveix com una porta directa per escapar d'entorns virtualitzats com els clústers de Kubernetes i comprometre el node principal.
Pegats d'emergència i solucions de mitigació
Davant la gravetat d'aquesta fallada, els equips de manteniment han desplegat actualitzacions d'emergència, on la solució definitiva rau a revertir l'optimització in-place dins l'arxiu algif_aead.c, separant estrictament les llistes de memòria d'origen i destí per evitar que les pàgines de la memòria cau acabin en rutes escrivibles.
Aquests pegats ja s'han integrat als nuclis 6.18.22, 6.19.12 i 7.0, i s'estan adaptant (backports) a les branques de suport a llarg termini. Per als administradors que no puguin reiniciar o actualitzar els seus servidors immediatament, es recomana deshabilitar el mòdul del nucli algif_aead si va ser compilat externament, o restringir severament la creació de sockets AF_ALG mitjançant polítiques de seguretat com SELinux, un blindatge que, per exemple, ha mantingut els dispositius Android actuals fora de perill.
Finalment, si estàs interessat en poder conèixer més sobre això, pots consultar els detalls al següent enllaç.