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
