VMime uuencode decoder: an unsigned underflow of the read length drives an out-of-bounds write on the stack while decoding a crafted MIME body #362

Activity

1. vincent-richard

   added a commit that references this issue on Oct 22, 2026

   uuEncoder: fix out-of-bounds write and several decoding bugs

   ...

   This issue will close once commit ea5afc6 is merged into the 'master' branch.

   ea5afc6
2. vincent-richard commented on Oct 22, 2026

   

   vincent-richard

   on Oct 22, 2026

   Member

   More actions

   Hi @Haind03,

   Thank you for the report and for the detailed write-up, it made the issue easy to confirm and fix.

   I confirm both findings. I checked the trace against the source and it holds:

   • Finding 1: when a line starts with b but is not a begin line, the probe leaves inPos at 5 while inLength is 2, and inLength - inPos wraps around. The two stream adapters then pass the huge count through, because their bounds checks (pos + count >= end) overflow too.
   • Finding 2: with a line length above 48, out.write() emits up to 15 bytes of outBuffer that were never written.

   The fix is in #363:

   • the decoder stops when the marker probe has consumed more than the line holds, and the line length is clamped so that only decoded bytes are written out;
   • inputStreamStringAdapter and seekableInputStreamRegionAdapter now compare the count with the remaining bytes, so a wrapped count can no longer get through to the copy;
   • regression tests cover both cases, as well as the adapters.

   While I was in this code, I also fixed some decoding bugs: lines whose length is not a multiple of 3 were not read entirely, the filename from the begin line included the mode, and a begin line with no mode and no filename swallowed the next line.

   You are credited in the commit message. If you have time to look at the PR, feedback is welcome.

   Thanks again!
3. vincent-richard

   closed this as completedin e85925eon Oct 23, 2026