#1144645 antiword: heap out-of-bounds write during Unicode font-name conversion

Package:
antiword
Source:
antiword
Description:
Converts MS Word files to text, PS, PDF and XML
Submitter:
vulnreport
Date:
2026-08-17 14:49:01 UTC
Severity:
normal
Tags:
#1144645#5
Date:
2026-08-17 14:23:14 UTC
From:
To:
Dear Maintainer,

I am reporting on behalf of an engineer at Quarkslab, a heap out-of-bounds write in antiword 0.37-17 when processing a malformed font-family name from a Word document.

The issue occurs in unincpy in misc.c.

unincpy copies n translated characters into its destination while reading two bytes from the source for every iteration:

    for (pcDest = s1, tLen = 0; tLen < n; pcDest++, tLen++) {
        usUni = usGetWord(tLen * 2, s2);
        ...
        *pcDest = (char)ulChar;
    }

In the vulnerable path, the source is the document-controlled aucFont font-name data and the destination is the fixed-size szWordFontname field.

There is no validation that the source contains 2*n bytes or that the destination has capacity for n output bytes.

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.

CWE: CWE-787 (Out-of-bounds Write)
             CWE-120 (Buffer Copy without Checking Size of Input)

Security impact
===============

The destination overflow corrupts adjacent heap memory. Our analysis indicates that the resulting heap corruption could potentially be used toward code execution with appropriate heap layout/grooming. Reliable arbitrary code execution has not been demonstrated.

Reproduction
============

With the attached PoC document:

    antiword -a a4 ./sample_oob_write_2.doc

Expected behavior:
antiword should validate both the source length and destination capacity before performing the conversion.

The issue was reproduced with antiword 0.37-17.

I have attached the PoC document and a detailed technical report.

Regards,
Salwa Souaf
Quarkslab VulnReport Team