g17hubh4ck/cve-2026-55781-pocUnbounded memory allocation in NanaZip's UFS handler via an attacker-controlled `fs_bsize` field.
# CVE-2026-55781 — NanaZip UFS Parser DoS
Unbounded memory allocation in NanaZip's UFS handler via an attacker-controlled `fs_bsize` field.
## Summary
| Field | Value |
|---|---|
| **CVE** | CVE-2026-55781 |
| **Advisory** | GHSA-m34h-jf84-m74h |
| **Vendor** | [M2Team / NanaZip](https://github.com/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 |
## Root Cause
`NanaZip.Codecs.Archive.Ufs.cpp` reads the UFS superblock and validates
`fs_bsize` against a **lower** bound only (`MINBSIZE`). No upper bound is
enforced before the value is used to size allocations.
When the root inode (`#2`) declares a `di_size` large enough to require
indirect blocks, the parser allocates one buffer per indirect level using
`fs_bsize`. Setting `fs_bsize = 0x40000000` (1 GiB) and
`di_size = 0x10000000000` (1 TiB) forces three 1 GiB allocations
(`Ufs.cpp:435-437`) — roughly **3 GiB** of contiguous memory — before any
bounds check runs.
Result: memory exhaustion and process termination. No code execution.
## Crafted Image Layout
| Region | Offset | Notes |
|---|---|---|
| Root inode `#2` | `512` | `ufs2_dinode`, 256 bytes, `di_mode = IFDIR`, `di_size = 1 TiB` |
| UFS2 superblock | `65536` (`SBLOCK_UFS2`) | `struct fs`, little-endian, `fs_bsize = 0x40000000` |
| Total size | `66912` bytes | `SBLOCK_UFS2 + sizeof(struct fs)` |
Key superblock fields (offsets from `offsetof(struct fs, ...)` in FreeBSD `fs.h`):
| Offset | Field | Value |
|---|---|---|
| `+16` | `fs_iblkno` | `0` |
| `+44` | `fs_ncg` | `1` |
| `+48` | `fs_bsize` | `0x40000000` ← malicious |
| `+52` | `fs_fsize` | `1` |
| `+56` | `fs_frag` | `1` |
| `+104` | `fs_sbsize` | `1376` |
| `+1000` | `fs_sblockloc` | `65536` |
| `+1372` | `fs_magic` | `0x19540119` (`FS_UFS2_MAGIC`) |
Root inode address: `GetInodeOffset(2) = fs_iblkno * fs_fsize + 2 * 256 = 512`.
## Usage
```bash
python3 poc.py poc.img
The script writes the malformed image and re-parses it to confirm every field landed where the vulnerable parser expects. No network access, no subprocesses, no weaponized payload — the carrier file alone is harmless.
Verification
The generated image can be inspected without NanaZip:
xxd -s 65536 -l 64 poc.img # superblock header
xxd -s 512 -l 32 poc.img # root inode header
To observe the crash, open poc.img with a vulnerable build on Windows. 6.5.1749.0 and later handle the input correctly.
Note: This PoC was constructed by static analysis of the NanaZip.Codecs parser. It reaches the exact vulnerable line documented in the advisory but was not executed against a running NanaZip build.
Mitigation
· Upgrade to NanaZip >= 6.5.1749.0. · If upgrade is not possible, avoid opening UFS images from untrusted sources.
References
· NanaZip: https://github.com/M2Team/NanaZip · Advisory: GHSA-m34h-jf84-m74h · CWE-789: https://cwe.mitre.org/data/definitions/789.html
Disclaimer
This material is provided for defensive research and vulnerability reproduction in controlled environments only. Do not use it against systems you do not own or have explicit permission to test.