g17hubh4ck/cve-2026-55781-pocAlocação de memória ilimitada no manipulador UFS do NanaZip por meio de um campo `fs_bsize` controlado pelo atacante.
| Campo | Valor |
|---|
| CVE | CVE-2026-55781 |
| Advisory | GHSA-m34h-jf84-m74h |
| Fornecedor | M2Team / NanaZip |
| Afetado | NanaZip <= 6.5 Preview (6.5.1742.0) |
| Corrigido | 6.5.1749.0 |
| Classe | Negação de Serviço (CWE-789: Alocação de Memória com Valor de Tamanho Excessivo) |
| Plataforma | Windows |
| Autor | g17hubH4ck |
| Divulgado | 2026-07-17 |
NanaZip.Codecs.Archive.Ufs.cpp lê o superbloco UFS e valida
fs_bsize apenas contra um limite inferior (MINBSIZE). Nenhum limite
superior é imposto antes que o valor seja usado para dimensionar alocações.
Quando o inode raiz (#2) declara um di_size grande o suficiente para exigir
blocos indiretos, o parser aloca um buffer por nível indireto usando
fs_bsize. Definir fs_bsize = 0x40000000 (1 GiB) e
di_size = 0x10000000000 (1 TiB) força três alocações de 1 GiB
(Ufs.cpp:435-437) — aproximadamente 3 GiB de memória contígua — antes que
qualquer verificação de limites seja executada.
Resultado: esgotamento de memória e encerramento do processo. Sem execução de código.
| Região | Offset | Notas |
|---|---|---|
Inode raiz #2 | 512 | ufs2_dinode, 256 bytes, di_mode = IFDIR, di_size = 1 TiB |
| Superbloco UFS2 | 65536 (SBLOCK_UFS2) | struct fs, little-endian, fs_bsize = 0x40000000 |
| Tamanho total | 66912 bytes | SBLOCK_UFS2 + sizeof(struct fs) |
Campos-chave do superbloco (offsets de offsetof(struct fs, ...) em fs.h do FreeBSD):
| Offset | 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) |
Endereço do inode raiz: GetInodeOffset(2) = fs_iblkno * fs_fsize + 2 * 256 = 512.
python3 poc.py poc.img
O script grava a imagem malformada e a reanalisa para confirmar que cada campo ficou onde o parser vulnerável espera. Sem acesso à rede, sem subprocessos, sem payload armamentizado — o arquivo transportador por si só é inofensivo.
Verificação
A imagem gerada pode ser inspecionada sem o NanaZip:
xxd -s 65536 -l 64 poc.img # superblock header
xxd -s 512 -l 32 poc.img # root inode header
Para observar o crash, abra poc.img com uma build vulnerável no Windows. 6.5.1749.0 e posteriores tratam a entrada corretamente.
Nota: Este PoC foi construído por análise estática do parser NanaZip.Codecs. Ele atinge a linha vulnerável exata documentada no advisory, mas não foi executado contra uma build do NanaZip em execução.
Mitigação
· Atualize para NanaZip >= 6.5.1749.0. · Se a atualização não for possível, evite abrir imagens UFS de fontes não confiáveis.
Referências
· NanaZip: https://github.com/M2Team/NanaZip · Advisory: GHSA-m34h-jf84-m74h · CWE-789: https://cwe.mitre.org/data/definitions/789.html
Aviso Legal
Este material é fornecido apenas para pesquisa defensiva e reprodução de vulnerabilidades em ambientes controlados. Não o use contra sistemas que você não possui ou para os quais não tem permissão explícita de teste.