g17hubh4ck/cve-2026-55781-pocAllocation mémoire non bornée dans le gestionnaire UFS de NanaZip via un champ `fs_bsize` contrôlé par l'attaquant.
| Champ | Valeur |
|---|
| CVE | CVE-2026-55781 |
| Avis | GHSA-m34h-jf84-m74h |
| Éditeur | M2Team / NanaZip |
| Affecté | NanaZip <= 6.5 Preview (6.5.1742.0) |
| Corrigé | 6.5.1749.0 |
| Classe | Déni de service (CWE-789 : Memory Allocation with Excessive Size Value) |
| Plateforme | Windows |
| Auteur | g17hubH4ck |
| Divulgué | 2026-07-17 |
NanaZip.Codecs.Archive.Ufs.cpp lit le superbloc UFS et valide
fs_bsize uniquement par rapport à une borne inférieure (MINBSIZE). Aucune borne supérieure n'est
appliquée avant que la valeur ne soit utilisée pour dimensionner les allocations.
Lorsque l'inode racine (#2) déclare un di_size suffisamment grand pour nécessiter des
blocs indirects, le parseur alloue un tampon par niveau d'indirection en utilisant
fs_bsize. Définir fs_bsize = 0x40000000 (1 Gio) et
di_size = 0x10000000000 (1 Tio) force trois allocations de 1 Gio
(Ufs.cpp:435-437) — environ 3 Gio de mémoire contiguë — avant qu'une quelconque
vérification de bornes ne soit exécutée.
Résultat : épuisement de la mémoire et arrêt du processus. Aucune exécution de code.
| Région | Offset | Notes |
|---|---|---|
Inode racine #2 | 512 | ufs2_dinode, 256 octets, di_mode = IFDIR, di_size = 1 Tio |
| Superbloc UFS2 | 65536 (SBLOCK_UFS2) | struct fs, little-endian, fs_bsize = 0x40000000 |
| Taille totale | 66912 octets | SBLOCK_UFS2 + sizeof(struct fs) |
Champs clés du superbloc (offsets depuis offsetof(struct fs, ...) dans fs.h de FreeBSD) :
| Offset | Champ | Valeur |
|---|---|---|
+16 | fs_iblkno | 0 |
+44 | fs_ncg | 1 |
+48 | fs_bsize | 0x40000000 ← malveillant |
+52 | fs_fsize | 1 |
+56 | fs_frag | 1 |
+104 | fs_sbsize | 1376 |
+1000 | fs_sblockloc | 65536 |
+1372 | fs_magic | 0x19540119 (FS_UFS2_MAGIC) |
Adresse de l'inode racine : GetInodeOffset(2) = fs_iblkno * fs_fsize + 2 * 256 = 512.
python3 poc.py poc.img
Le script écrit l'image malformée et la re-parse pour confirmer que chaque champ se trouve là où le parseur vulnérable l'attend. Aucun accès réseau, aucun sous-processus, aucune charge utile weaponisée — le fichier porteur seul est inoffensif.
Vérification
L'image générée peut être inspectée sans NanaZip :
xxd -s 65536 -l 64 poc.img # superblock header
xxd -s 512 -l 32 poc.img # root inode header
Pour observer le crash, ouvrez poc.img avec une version vulnérable sous Windows. 6.5.1749.0 et versions ultérieures traitent correctement l'entrée.
Remarque : ce PoC a été construit par analyse statique du parseur NanaZip.Codecs. Il atteint la ligne vulnérable exacte documentée dans l'avis, mais n'a pas été exécuté contre une version de NanaZip en fonctionnement.
Atténuation
· Mettre à niveau vers NanaZip >= 6.5.1749.0. · Si la mise à niveau n'est pas possible, évitez d'ouvrir des images UFS provenant de sources non fiables.
Références
· NanaZip : https://github.com/M2Team/NanaZip · Avis : GHSA-m34h-jf84-m74h · CWE-789 : https://cwe.mitre.org/data/definitions/789.html
Avertissement
Ce matériel est fourni à des fins de recherche défensive et de reproduction de vulnérabilité dans des environnements contrôlés uniquement. Ne l'utilisez pas contre des systèmes que vous ne possédez pas ou pour lesquels vous ne disposez pas d'une autorisation explicite de test.