Hello Olly,
Thank you for your feedback on the reported vulnerabilities.
The engineer who initially identified the vulnerabilities had since moved on to
other projects and has only recently had the opportunity to provide the
necessary follow-up. We apologize for the delay and appreciate your patience.
The patch for the bug 1144645 is prone to an underflow in the newly added
comparison:
if (tFontTableRecords - (pTmp - pFontTable) <=4 ) {
...
}
tFontTableRecords is read from the file and its value can be 0, resulting in an
underflow which will wrap the integer to 2^64-1 and will bypass the comparison.
Changing the patch to something like the following takes into account the
possible underflow:
if ((pTmp - pFontTable) > tFontTableRecords || tFontTableRecords - (pTmp -
pFontTable) <= 4) {
...
}
Finally, this comparison should be done before the first call to
vFontname2Table because the previous condition can be true on the first
iteration of the loop if tFontTableRecords is 0.
The bugs 1144643, 1144640, 1144641, 1144642 (and 1144645 once the patch is
fixed) are now patched; would CVEs be attributed to them, to make it easier to
report the vulnerabilities to maintainers from other distributions?
Best regards,
Salwa
________________________________
From: Olly Betts <[email protected]>
Sent: Monday, August 24, 2026 4:57 AM
To: [email protected] <[email protected]>
Cc: vulnreport <[email protected]>
Subject: Re: Bug#1144645: antiword: heap out-of-bounds write during Unicode
font-name conversion
Control: tag 1144645 + pending
Control: clone 1144645 -1
Control: retitle -1 antiword: heap out-of-bounds read during Unicode font-name
conversion
Control: severity -1 normal
On Sun, Aug 23, 2026 at 11:44:48PM +0100, Olly Betts wrote:
> On Mon, Aug 17, 2026 at 02:23:14PM +0000, vulnreport wrote:
> > A malformed font-family name can therefore cause both an out-of-bounds read
> > of the source and writes past the destination font-name buffer.
>
> I think you've misunderstood what's happening here. The problem actually
> seems
> to be that pFontTableRecord is past the end of pFontTable. If I apply this
> patch then antiword exists with "XXX":
>
> --- a/fonts.c
> +++ b/fonts.c
> @@ -865,6 +865,9 @@ vCreate8FontTable(FILE *pFile, const pps_info_type *pPPS,
> NO_DBG_UNICODE(aucFont);
> NO_DBG_UNICODE(aucAltFont);
> }
> + if (pTmp - pFontTable >= tFontTableRecords) {
> + werr(1, "XXX\n");
> + }
> vFontname2Table(aucFont, aucAltFont, 2, iEmphasis,
> ucFFN, szWordFont, szOurFont, pTmp);
> pTmp += 4;
I have a fix for this (and two similar cases for the font table handling
for other versions of the file format).
The OOB read is not really the same problem so I've split that into a
new bug.
Cheers,
Olly
