Re: [PATCH] Src/parse.c: bound h->npats in .zwc loader
Bart Schaefer <[email protected]>
| Newsgroups | gmane.comp.shells.zsh.devel |
|---|---|
| Message-ID | <CAH+w=7a+QVgnSSvx_LwQYzry2A3NQfLoAw+oVO=YEcJ4e3toRA@mail.gmail.com> |
On Thu, May 14, 2026 at 11:07 PM Michael Ridgway <[email protected]> wrote: > > Background. The .zwc loader at Src/parse.c:3920 computes > > int po = h->npats * sizeof(Patprog); > > with h->npats an attacker-controlled uint32 from the .zwc header. > > This patch uses a file-derived structural bound instead. Every > pattern emitted into the wordcode stream costs exactly one wordcode > (parse.c:1307, 1316, 1352, 2667, 2673, 2679, 2684 -- all of the form > ecadd(ecnpats++)), so a file claiming more patterns than it has > wordcodes to reference them with is malformed by construction: > > h->npats > h->len / sizeof(wordcode) Pardon that I'm commenting without code-parsing, but could this be subverted by creating an extremely large .zwc file? Possibly just by appending a block of NULL bytes when modifying the npats header? Not to imply that this should be left unfixed, and the variable type/size corrections are good, but it should be noted as was pointed out in the security thread that an attacker-controlled .zwc file is always a vulnerability.