IndexOutOfBoundsException in PdfReader
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 70/100
Research direction
Start with openpdf-core/src/main/java/org/openpdf/text/pdf/PdfReader.java, focusing on readDocObj near the reported line and readXrefStream near line 2294. Compare the bounds check in getPdfObject(int idx) with the object stream lookup, then run or add a regression test for a malformed xref stream whose object number exceeds the parsed object list. Done means parsing no longer throws the raw IndexOutOfBoundsException for that input.
Written by the indexing model from the issue text.
Description
IndexOutOfBoundsException in PdfReader
Describe the bug
java.lang.IndexOutOfBoundsException: Index 57407 out of bounds for length 899
at java.util.ArrayList.get
at com.lowagie.text.pdf.PdfReader.readDocObj(PdfReader.java:1957)
at com.lowagie.text.pdf.PdfReader.<init>
Root cause: The full stack shows the exception originates inside the OpenPDF library.
57407 is a PDF object number and 899 the parsed-object-list size — the classic signature of a broken PDF cross-reference table. Invoice.writePdf merges each invoice attachment's stored bytes, and PdfDocument.write re-parses each with OpenPDF's PdfReader. One attachment on this invoice is a corrupt/malformed PDF whose xref points at object 57407 while only 899 exist → the legacy reader throws a raw IndexOutOfBoundsException instead of a clean parse error.
Preview of a preliminary project invoice. Single occurrence for this exact stack signature in the retained window; deterministic for the one corrupt attachment, no loop / no data corruption / no retry-storm. Company & user details withheld here per sensitive-data policy.
Fails only the one request, but blocks every PDF render of that invoice (preview/print/likely send) until the bad attachment is removed. Same class recurs for any invoice carrying a corrupt PDF attachment.
Master branch:
https://github.com/LibrePDF/OpenPDF/blob/master/openpdf-core/src/main/java/org/openpdf/text/pdf/PdfReader.java#L1965
2.0.3 version:
https://github.com/LibrePDF/OpenPDF/blob/2.0.3/openpdf/src/main/java/com/lowagie/text/pdf/PdfReader.java#L1957
Summary of the report: IndexOutOfBoundsException in PdfReader when parsing a PDF with a corrupt/malformed cross-reference (xref) stream — an object number referenced by the xref stream exceeds the size of the parsed object list.
What I verified in the current code (openpdf-core/src/main/java/org/openpdf/text/pdf/PdfReader.java):
- readXrefStream (~line 2294-2318): when parsing a cross-reference stream (type 2 entries, i.e. compressed objects living inside an object stream), it reads field2 — the object number of the containing object stream — directly from stream bytes and stores it as a key in objStmMark via objStmMark.put(on, seq). This value is never bounds-checked against the actual parsed object count; ensureXrefSize is only called for start/length (the compressed object's own number), not for field2.
- readDocObj (line 1965):
readObjStm((PRStream) xrefObj.get(n), h); - n comes straight from an objStmMark key — no range check before calling .get(n).
- Contrast with getPdfObject(int idx) (line 1738-1744), just ~200 lines above, which does the correct thing:
if (idx < 0 || idx >= xrefObj.size()) {
return null;
}
That inconsistency is exactly the bug: one accessor validates bounds, the other doesn't, and a malformed/corrupt xref stream can point at an object number (e.g. 57407) far beyond the actual object list size (e.g. 899), producing the raw ArrayList.get IndexOutOfBoundsException instead of a handled parse error.
Conclusion: Yes, still a valid, unfixed bug on master. It's a missing-bounds-check issue, not something masked by input sanitization elsewhere, and it also affects 2.0.3 as noted in the issue.
Fix would be small: add the same n < 0 || n >= xrefObj.size() guard at line 1965 (skip/log and continue rather than crash), and ideally validate field2 in readXrefStream before storing it in objStmMark.
System
- OS: Ubuntu Linux
- OpenPDF version: 2.0.3
Your real name
Andreas Røsdal
- Dominant language
- Java
- Stars
- 4.4k
- Forks
- 714
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from LibrePDF/OpenPDF
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
`PdfSmartCopy` can take effectively unbounded time on nested shared Form XObjectsPossibly taken A pull request linked to this issue is open or already merged. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 38/100
-
Difficulty 4/5 1-2 days Newbie friendliness 45/100
All issues in LibrePDF/OpenPDF
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
geonetwork/core-geonetwork#9592 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/rocketmq-dashboard#7361 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
higress-group/himarket#358 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day