Reject invalid WMF unitsPerInch=0 to prevent infinite scaling

[jmestwa-coder]

Summary

Reject invalid WMF files where unitsPerInch = 0 to prevent unsafe scaling behavior.

---

Problem

unitsPerInch from the placeable WMF header is used as a divisor in scaling calculations.

If it is 0, this leads to:

• Division by zero
• Infinite dimensions
• Potentially excessive image allocation

This originates from externally supplied WMF input.

---

Root Cause

unitsPerInch is not validated before being used in scaling.

---

Fix

• Read unitsPerInch as unsigned (readUShort)
• Reject unitsPerInch == 0 at the parser boundary by throwing RecordFormatException

---

Why This Change

Allowing unitsPerInch = 0 produces infinite dimensions during scaling, which can result in unsafe memory allocation.

Rejecting this value prevents undefined and unsafe behavior during WMF processing.

---

Tests

• Added regression test for unitsPerInch = 0 → verifies rejection
• Added valid case → verifies finite, positive dimensions

Tests are deterministic and in-memory.

---

Compatibility

• No API changes
• No behavior change for valid WMF files
• Only invalid input is rejected

[pjfanning]

@jmestwa-coder can you describe what happens when the new tests are run without the main source change? Maybe the tests could be documented with this detail.

[pjfanning]

add RecordFormatException to the throws clause

[jmestwa-coder]

I’ve updated the constructor signature to explicitly declare RecordFormatException for consistency with the parsing code.

[jmestwa-coder]

here’s what happens when the new tests are run without this change:

When unitsPerInch = 0 is parsed, it is later used as a divisor during scaling. This results in infinite dimensions.

Those values are then used when creating the BufferedImage, where they get converted to integers. In practice, this can turn into very large dimensions (close to Integer.MAX_VALUE), which may lead to excessive memory allocation attempts or runtime failures.

So without this fix:

• The parser accepts unitsPerInch = 0
• Scaling produces infinite dimensions
• Rendering may attempt to allocate extremely large images

With this change:

• The invalid value is rejected early at the parser boundary
• The unsafe scaling and allocation path is never reached