valerybokov opened a new pull request, #484: URL: https://github.com/apache/pdfbox/pull/484
## Summary `CCITTFactory.readlong()` reads a TIFF `LONG` field (an unsigned 32-bit value per the TIFF spec) by assembling four bytes with an `int`, then returning that `int`. At the call site (`long address = readlong(...)`), the `int` is widened to `long`, which in Java **sign-extends**. If the top bit of the 32-bit value is set (i.e. the raw value is `>= 0x80000000`), the widened `long` becomes a large *negative* number instead of the correct unsigned value — corrupting IFD offsets used directly in `reader.seek(address)`. In practice this is latent rather than commonly hit: classic TIFF (non-BigTIFF) is capped near 4GB by its own 32-bit offset fields, and CCITT G3/G4-compressed files in particular are typically KB-to-low-MB in size, so authentic offsets essentially never cross that boundary. The realistic risk is a malformed/corrupted/adversarial TIFF whose 4-byte offset or count field has the high bit set — `readlong` trusts those bytes without validating against the actual file size, so such input silently produces a corrupted negative seek target rather than a controlled error. ## Fix - fix warning for `readlong` method - `readlong` now returns `long` and masks the assembled value with `& 0xFFFFFFFFL`, so it's always treated as unsigned when read. - `address` (already declared `long`) now receives the correct unsigned value automatically. - `count` and `val`, which are intentionally kept as `int` (small tag values used with `params.setInt(...)` / buffer sizes), now narrow explicitly via `(int)` casts — same bit pattern as before, so their behavior is unchanged. ## Test plan Added `CCITTFactoryTest#testReadLongIsUnsigned`, which invokes the private `readlong` via reflection against crafted byte sequences with the high bit set (`0xFFFFFFFF` and `0x80000000`, in both byte orders) and asserts the returned `long` is the correct non-negative unsigned value. - Verified the test fails against the pre-fix `int`-returning implementation (e.g. expected `4294967295`, got `-1`) and passes against the fix. - Existing `CCITTFactoryTest` suite (small real-world CCITT G3/G4 fixtures) continues to pass — those files never exercised this path since their offsets are well under `0x80000000`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
