g17hubh4ck/cve-2026-55781-pocAllocazione di memoria illimitata nel gestore UFS di NanaZip tramite un campo `fs_bsize` controllato dall'attaccante.
| Campo | Valore |
|---|
| CVE | CVE-2026-55781 |
| Advisory | GHSA-m34h-jf84-m74h |
| Vendor | M2Team / NanaZip |
| Affected | NanaZip <= 6.5 Preview (6.5.1742.0) |
| Fixed | 6.5.1749.0 |
| Class | Denial of Service (CWE-789: Memory Allocation with Excessive Size Value) |
| Platform | Windows |
| Author | g17hubH4ck |
| Disclosed | 2026-07-17 |
NanaZip.Codecs.Archive.Ufs.cpp legge il superblocco UFS e convalida
fs_bsize solo rispetto a un limite inferiore (MINBSIZE). Nessun limite
superiore viene applicato prima che il valore sia utilizzato per dimensionare
le allocazioni.
Quando l'inode radice (#2) dichiara un di_size abbastanza grande da
richiedere blocchi indiretti, il parser alloca un buffer per ogni livello
indiretto usando fs_bsize. Impostando fs_bsize = 0x40000000 (1 GiB) e
di_size = 0x10000000000 (1 TiB) si forzano tre allocazioni da 1 GiB
(Ufs.cpp:435-437) — circa 3 GiB di memoria contigua — prima che venga
eseguito qualsiasi controllo dei limiti.
Risultato: esaurimento della memoria e terminazione del processo. Nessuna esecuzione di codice.
| Regione | Offset | Note |
|---|---|---|
Inode radice #2 | 512 | ufs2_dinode, 256 byte, di_mode = IFDIR, di_size = 1 TiB |
| Superblocco UFS2 | 65536 (SBLOCK_UFS2) | struct fs, little-endian, fs_bsize = 0x40000000 |
| Dimensione totale | 66912 byte | SBLOCK_UFS2 + sizeof(struct fs) |
Campi chiave del superblocco (offset da offsetof(struct fs, ...) in fs.h di FreeBSD):
| Offset | Campo | Valore |
|---|---|---|
+16 | fs_iblkno | 0 |
+44 | fs_ncg | 1 |
+48 | fs_bsize | 0x40000000 ← malevolo |
+52 | fs_fsize | 1 |
+56 | fs_frag | 1 |
+104 | fs_sbsize | 1376 |
+1000 | fs_sblockloc | 65536 |
+1372 | fs_magic | 0x19540119 (FS_UFS2_MAGIC) |
Indirizzo dell'inode radice: GetInodeOffset(2) = fs_iblkno * fs_fsize + 2 * 256 = 512.
python3 poc.py poc.img
Lo script scrive l'immagine malformata e la ri-analizza per confermare che ogni campo sia finito dove il parser vulnerabile se lo aspetta. Nessun accesso alla rete, nessun sottoprocesso, nessun payload weaponizzato — il file carrier da solo è innocuo.
Verifica
L'immagine generata può essere ispezionata senza NanaZip:
xxd -s 65536 -l 64 poc.img # superblock header
xxd -s 512 -l 32 poc.img # root inode header
Per osservare il crash, aprire poc.img con una build vulnerabile su Windows. 6.5.1749.0 e versioni successive gestiscono correttamente l'input.
Nota: questo PoC è stato costruito tramite analisi statica del parser NanaZip.Codecs. Raggiunge la riga vulnerabile esatta documentata nell'advisory ma non è stato eseguito contro una build di NanaZip in esecuzione.
Mitigazione
· Aggiornare a NanaZip >= 6.5.1749.0. · Se l'aggiornamento non è possibile, evitare di aprire immagini UFS da fonti non attendibili.
Riferimenti
· NanaZip: https://github.com/M2Team/NanaZip · Advisory: GHSA-m34h-jf84-m74h · CWE-789: https://cwe.mitre.org/data/definitions/789.html
Disclaimer
Questo materiale è fornito esclusivamente per la ricerca difensiva e la riproduzione di vulnerabilità in ambienti controllati. Non utilizzarlo contro sistemi di cui non si è proprietari o per cui non si ha esplicita autorizzazione ai test.