New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
heap-buffer-overflow in libsixel/src/quant.c:867 #25
Comments
|
great work! certainly looks valid to me. i'll try to have a fix up by tomorrow morning, but if anyone else wants to offer one in the meantime, i'll evaluate it. well done! =] |
|
alright, so the fix seems pretty simple -- don't diffuse into the void. |
|
I've put up a PR which I'm pretty sure closes this problem. I still see plenty of uses of uninitialized data in a valgrind run, but no longer any invalid accesses. |
|
Fix pushed in 1.10.0. |
|
Could I try to submit this problem to get CVE ID? |
you can do whatever you like, though i doubt it's very easy to turn this into an exploit. |
Hi,I found a heap-buffer-overflow in the current master 705d991
It sames with the saitoha/libsixel/issue#156 (I found this problem 2 days ago)
OS: Ubuntu 20.04.3 LTS x86_64
Kernel: 5.11.0-27-generic
POC: poc.zip
It's the command line's report:
and here is the ASAN report for saitoha/libsixel (the current master [6a5be8b]):
It happens on:
https://github.com/saitoha/libsixel/blob/6a5be8b72d84037b83a5ea838e17bcf372ab1d5f/src/quant.c#L1002
same with:
libsixel/src/quant.c
Line 993 in 705d991
when x=0, y=0, width=1,then
gdb info:

In this position,[r13+rcx*1+0x0] will be
0x100000000000f7e6d=>0xf7e6dSo,writing to data will cause
overflowand then it writes to a location (chunk) in the heap that should not be written to.
heap info:
Before:
After:
The text was updated successfully, but these errors were encountered: