Fix possible out of bounds read in PDF parser #1362
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
find_length()
function in the PDF parser incorrectly assumes that objects found are located in the main PDF file map, and fails to take into account whether the objects were in fact found in extracted PDF object streams. The resulting pointer is then invalid and may be an out of bounds read.This issue was found by OSS-Fuzz.
This fix checks if the object is from an object stream, and then calculates the pointer based on the start of the object stream instead of based on the start of the PDF.
I've also added extra checks to verify the calculated pointer and object size are within the stream (or PDF file map). I'm not entirely sure this is necessary, but better safe than sorry.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=69617
Note: This is fixed in the recently released security patch versions: https://blog.clamav.net/2024/09/clamav-141-132-107-and-010312-security.html