Bug 703902 - More poor stack op management causing a crash
Summary: More poor stack op management causing a crash
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Fuzzing (show other bugs)
Version: master
Hardware: All All
: P4 normal
Assignee: Chris Liddell (chrisl)
QA Contact: Bug traffic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-01 18:55 UTC by Chris Liddell (chrisl)
Modified: 2021-07-12 16:03 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
file from oss-fuzz showing crash (5.00 KB, application/postscript)
2021-06-01 18:55 UTC, Chris Liddell (chrisl)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Liddell (chrisl) 2021-06-01 18:55:01 UTC
Created attachment 21042 [details]
file from oss-fuzz showing crash

From:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34675

sampled_data_continue() uses the "pop()" macro badly. All that macro does is decrement the pointer indicating the top item on the op stack - it does no underflow checking, nor does it account for dropping off the bottom of the current stack "block" (if the op stack has been extended).

As such, it is intended to only be called as the *very* last thing before returning to the main interpreter loop, which *does* check for underflow and stack extension blocks, and so on.

The problem in sampled_data_continue() uses pop() (several times) then calls sampled_data_sample() which also access the stack.

In this example file, that causes the top of the stack pointer to decrement off the end of the current extension block, and nothing deals with that before the next stack access happens.