Re: libmspack: heap buffer overflow in make_decode_table() (Huffman decode table construction) -- CVE requested

[Sam James <sam () gentoo org>]

Sumit Chakraborty <sumit.ch2004 () gmail com> writes:

> Hi all,
>
> Reporting a memory-safety issue found via independent source audit of
> libmspack (https://github.com/kyz/libmspack), a small C library for
> Microsoft compression formats (CAB, CHM, LIT, HLP, KWAJ, SZDD) used by
> cabextract and vendored by ClamAV (libclammspack), among others.

Thanks for sharing and bringing it to the list.

> Summary: make_decode_table() in mspack/readhuff.h -- the shared Huffman
> decode-table builder used across the library's CAB/CHM/LZX decoders -- does
> not validate that its input code-length array satisfies Kraft's inequality
> before building extension nodes for long codes. A crafted, format-legal
> length distribution can cause it to write past the end of the
> caller-allocated decode table while still returning success, giving the
> caller no indication anything went wrong.
>
> I've confirmed this is reachable through real library API calls with a
> hand-crafted input file, not just direct/synthetic function calls, and
> precisely measured the resulting out-of-bounds write. I'm holding back
> further technical detail (exact trigger conditions, PoC construction,
> affected call sites) pending coordinated disclosure.
>
> Reported to the maintainer (Stuart Caie) directly by email on 2026-08-16.
> No CVE currently assigned. Requesting a CVE ID be reserved for tracking;
> full technical writeup and PoC will follow once a fix is available or a
> reasonable disclosure window has passed.

I'm not sure if I follow the purpose of the email. If you'd like to
handle disclosure to distros, you can use the linux-distros@ or distros@
mailing list as appropriate, provided you're able & willing to follow
the rules at
https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters.

If you're *not* interested in doing that, then we'd IMO generally like to
see some link to a bug report (that had gone unfixed), or a patch or PoC
or something. As it stands, all this post seems to signal is: there's a
bug; you found a bug; the maintainer knows about it; there is not much
actionable to remedy the bug.

It's not strictly wrong to post what you have but it's unusual and I am
not sure who or what it helps.

Am I missing something here? What was your intent with posting it at
this stage?

> Happy to share full details privately with anyone who needs them for triage
> (distro security teams, downstream maintainers, etc.) -- just reach out
> directly.
>
> Thanks,
> Sumit Chakraborty

thanks,
sam

Attachment: signature.asc
Description: