Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cups: gif reader infinite loop and heap buffer overflow #3867
Petr Sklenar created a fuzzed gif image which triggers a heap corruption in the GIF reading code in CUPS.
The file triggers stack buffer overflow in gif_read_lzw() in filter/image-gif.c. Relevant code part is (line numbers are for 1.4.6):
661 while (code >= clear_code)
This ensures that table[code] != code, but it's possible to create loop between multiple table entries, if table[code] > code. I believe that's an incorrect case that should be detected in this part of the code:
655 if (code >= max_code)
That's the code for the LZW decoding special case. code == max_code seems to be the correct check to be used there, with code > max_code being invalid and should be rejected.
I've actually had a look at couple of other code bases that seem to have GIF reader derived from the same implementation as the one used by CUPS. Some of them reject code > max_code:
while other check for stack overflow in the while() loop:
This should not have any bad security implications for CUPS beyond filter crash, as this keeps looping until some unmapped memory is hit, without trying to use corrupted memory. I'm tagging this as security so you can review and decide how you want to handle this. Please let me know if you prefer to handle this as embargoed, as there are few other projects that seem to have this problem.
CUPS.org User: thoger
One thing I realized later, the crash as described above depends on stack being located above the table. If memory allocator places it below, stack overflow can result in table modification, which can break the infinite loop, and the program may continue executing with corrupted heap.
--- filter/image-gif.c (revision 9839)
- table[i] = table = 0;
@@ -605,30 +599,31 @@
if (sp > stack)
- table[i] = table[i] = 0;
@@ -637,13 +632,12 @@
@@ -652,7 +646,7 @@
if (sp > stack)