g17hubh4ck/cve-2026-55781-pocAsignación de memoria sin límites en el controlador UFS de NanaZip a través de un campo `fs_bsize` controlado por el atacante.
| Campo | Valor |
|---|
| CVE | CVE-2026-55781 |
| Aviso | GHSA-m34h-jf84-m74h |
| Proveedor | M2Team / NanaZip |
| Afectado | NanaZip <= 6.5 Preview (6.5.1742.0) |
| Corregido | 6.5.1749.0 |
| Clase | Denegación de servicio (CWE-789: Asignación de memoria con valor de tamaño excesivo) |
| Plataforma | Windows |
| Autor | g17hubH4ck |
| Divulgado | 2026-07-17 |
NanaZip.Codecs.Archive.Ufs.cpp lee el superbloque UFS y valida
fs_bsize únicamente contra un límite inferior (MINBSIZE). No se
aplica ningún límite superior antes de que el valor se utilice para
dimensionar las asignaciones.
Cuando el inodo raíz (#2) declara un di_size lo suficientemente grande
como para requerir bloques indirectos, el analizador asigna un búfer por
cada nivel indirecto usando fs_bsize. Establecer fs_bsize = 0x40000000
(1 GiB) y di_size = 0x10000000000 (1 TiB) fuerza tres asignaciones de
1 GiB (Ufs.cpp:435-437) — aproximadamente 3 GiB de memoria contigua —
antes de que se ejecute cualquier comprobación de límites.
Resultado: agotamiento de memoria y terminación del proceso. Sin ejecución de código.
| Región | Desplazamiento | Notas |
|---|---|---|
Inodo raíz #2 | 512 | ufs2_dinode, 256 bytes, di_mode = IFDIR, di_size = 1 TiB |
| Superbloque UFS2 | 65536 (SBLOCK_UFS2) | struct fs, little-endian, fs_bsize = 0x40000000 |
| Tamaño total | 66912 bytes | SBLOCK_UFS2 + sizeof(struct fs) |
Campos clave del superbloque (desplazamientos desde offsetof(struct fs, ...) en fs.h de FreeBSD):
| Desplazamiento | Campo | Valor |
|---|---|---|
+16 | fs_iblkno | 0 |
+44 | fs_ncg | 1 |
+48 | fs_bsize | 0x40000000 ← malicioso |
+52 | fs_fsize | 1 |
+56 | fs_frag | 1 |
+104 | fs_sbsize | 1376 |
+1000 | fs_sblockloc | 65536 |
+1372 | fs_magic | 0x19540119 (FS_UFS2_MAGIC) |
Dirección del inodo raíz: GetInodeOffset(2) = fs_iblkno * fs_fsize + 2 * 256 = 512.
python3 poc.py poc.img
El script escribe la imagen malformada y la vuelve a analizar para confirmar que cada campo quedó donde el analizador vulnerable lo espera. Sin acceso a red, sin subprocesos, sin carga útil armada — el archivo contenedor por sí solo es inofensivo.
Verificación
La imagen generada puede inspeccionarse sin NanaZip:
xxd -s 65536 -l 64 poc.img # superblock header
xxd -s 512 -l 32 poc.img # root inode header
Para observar el fallo, abra poc.img con una compilación vulnerable en Windows. 6.5.1749.0 y posteriores manejan la entrada correctamente.
Nota: Este PoC fue construido mediante análisis estático del analizador NanaZip.Codecs. Alcanza la línea vulnerable exacta documentada en el aviso, pero no fue ejecutado contra una compilación de NanaZip en funcionamiento.
Mitigación
· Actualice a NanaZip >= 6.5.1749.0. · Si la actualización no es posible, evite abrir imágenes UFS de fuentes no confiables.
Referencias
· NanaZip: https://github.com/M2Team/NanaZip · Aviso: GHSA-m34h-jf84-m74h · CWE-789: https://cwe.mitre.org/data/definitions/789.html
Descargo de responsabilidad
Este material se proporciona únicamente para investigación defensiva y reproducción de vulnerabilidades en entornos controlados. No lo utilice contra sistemas que no sean de su propiedad o para los que no tenga permiso explícito de realizar pruebas.