[
https://issues.apache.org/jira/browse/PDFBOX-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18009205#comment-18009205
]
Michael Klink commented on PDFBOX-6037:
---------------------------------------
Indeed, t's reasonable to check the sum of those *W* values (in {{parse}} a
{{byte[]}} as large as that sum is created), but IMO the proposed limit
{{MAX_LINE = 1000000}} still is too large; for most reasonable PDFs there
hardly is reason to even have a two-digit sum, so a {{MAX_LINE = 20}} would be
ok, too.
(Admittedly, there is no limit for the *W* values in the spec, so {{[7 7 7]}}
would be valid per se, but it would have quite a smell of a attempt to break
some tools.)
> Potential OOM in XrefStreamParser
> ---------------------------------
>
> Key: PDFBOX-6037
> URL: https://issues.apache.org/jira/browse/PDFBOX-6037
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
> Affects Versions: 4.0.0
> Reporter: David Justamante
> Priority: Minor
> Labels: patch
> Attachments: example.pdf, simple_patch.diff
>
>
> This issue is being _*manually*_ filed by the competition organizers. We
> recognize there is a number of AI generated submissions as of late. We have
> gone through the manual process of bug/patch validation to prevent
> unnecessary "noise", respecting maintainers' time.
> This submission is being sent as part of DARPA's AIxCC competition.
> ([https://aicyberchallenge.com)|https://aicyberchallenge.com)/] This issue
> was discovered by an autonomous Cyber Reasoning System (CRS) and validated by
> competition engineers. The patch was manually constructed by the competition
> engineers.
> XrefStreamParser - Read length then allocate without validation or bounds
> checking. This can cause OOM if heap is < 2g.
> We understand if this is a "won't fix" from an allocation perspective, but it
> feels like the allocation should happen after some verification that the
> stream is really there and really of that length.
> We're attaching a triggering file and an example simple patch that trivially
> sets a hard limit on the stream length. The example file was generated by
> competitor's system in the AIxCC competition.
> (AIxCC Internal: CHA-1725)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
