On Mon, Aug 17, 2026 at 02:23:14PM +0000, vulnreport wrote:
> There is no validation that the source contains 2*n bytes
This seems to be the case.
> or that the destination has capacity for n output bytes.
However this doesn't seem to be true to me. You don't explicitly give
the source location, but the only call which fits is this one in fonts.c:
(void)unincpy(pFontTableRecord->szWordFontname,
aucFont,
sizeof(pFontTableRecord->szWordFontname) - 1);
The value passed for n is one less than the size of the fixed szWordFontname
field.
> 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;
> antiword 0.37-17 from Ubuntu APT's sources
[...]
> git-ubuntu clone antiword
When reporting a bug to Debian please test using Debian's packages not those of
a derived distribution.
Cheers,
Olly
