Bug 703902

Summary: More poor stack op management causing a crash
Product: Ghostscript Reporter: Chris Liddell (chrisl) <chris.liddell>
Component: FuzzingAssignee: Chris Liddell (chrisl) <chris.liddell>
Status: RESOLVED FIXED QA Contact: Bug traffic <tech>
Severity: normal    
Priority: P4    
Version: master   
Hardware: All   
OS: All   
Customer: Word Size: ---
Attachments: file from oss-fuzz showing crash

Description Chris Liddell (chrisl) 2021-06-01 18:55:01 UTC
Created attachment 21042 [details]
file from oss-fuzz showing crash


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.