Dear Maintainer,

Dear Maintainer,

I found an out-of-bounds read while fuzzing Antiword 0.37 with AFL++.
The issue is reproducible against the Debian 0.37-18 source package when
built with AddressSanitizer.

A malformed .doc file containing a truncated Word 8 property modifier
causes an out-of-bounds read in the row-property parsing path.

AddressSanitizer reports:

    ERROR: AddressSanitizer: global-buffer-overflow
    READ of size 1
    #0 iGet8InfoLength .../prop8.c:42
    #1 eGet8RowInfo .../prop8.c:503
    #2 ePropMod2RowInfo .../properties.c:192

The invalid read occurs immediately after the static aucBuffer[4] in
propmod.c.

GDB showed the following state for the reproducer:

    usPropMod = 49152
    iLen = 2
    aucPropMod bytes = 02 00 00 c0

ePropMod2RowInfo() therefore passes a two-byte property region beginning
at aucBuffer+2 to eGet8RowInfo(). The resulting opcode is 0xc000.
iGet8InfoLength() handles this opcode class by reading an additional
operand byte at iByteNbr + 2, but only two bytes of property data are
available.

Reproduction:

1. Build Debian Antiword 0.37-18 with AddressSanitizer.
2. Run:

       ./antiword candidate-E-original.doc

3. AddressSanitizer reports a global-buffer-overflow in
   iGet8InfoLength() at prop8.c:42.

I have prepared a candidate patch which validates the available property
data before opcode-specific processing. During development, adding
validation only within iGet8InfoLength() exposed an earlier unchecked
property-specific access in eGet8RowInfo(), so the final fix performs
validation before opcode dispatch.

With the patch applied:
- the reproducer exits without an AddressSanitizer finding;
- the Candidate A reproducer also remains clean; and
- a valid .doc test file continues to process successfully without an
  AddressSanitizer finding.

I could not locate an existing Debian bug matching this specific
truncated property-modifier parsing issue.

I can provide the crashing .doc reproducer and candidate patch.