valerybokov opened a new pull request, #488: URL: https://github.com/apache/pdfbox/pull/488
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. ---------------------------------------------------------------- Per https://www.apache.org/legal/generative-tooling.html: portions of this PR (the `readlong()` fix in `CCITTFactory.java` and the accompanying `CCITTFactoryTest#testReadLongIsUnsigned` regression test) were produced with assistance from Claude Code (Anthropic), based on a bug I identified and directed the fix for. I've reviewed the generated code and test, verified the test fails against the pre-fix implementation and passes against the fix, and confirm to the best of my knowledge that the output does not include any third-party copyrighted material and is compatible with the Apache License 2.0. -- 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]
