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
Crash during multiple concurrent/parallel decoding #708
Comments
|
If I put following call for
|
|
I am able to reproduce the crash also via gdk-pixbuf loader which use ResizeableParallelRunner. It is enough to call following procedure in concurrently in multiple threads few times: |
|
|
|
@novomesk what's the source image for that .jxl file? Does it have a vertical green rectangle on the top right corner of the image by any chance? I'm not sure if that rectangle was on the source image or that's also a (maybe different) bug. I wasn't able to reproduce it directly with djxl but it has to do with the order in which the groups are processed so the more threads/CPUs you have the more likely it is. I was able to reliably reproduce it with an random-order single threaded parallel runner. |
|
I think I found the source image here: |
When processing groups out of order with an image where the last group size is smaller than the needed border it was possible to attempt to load the right or bottom border from the next group when already processing the rightmost or bottom group respectively. This situation was causing an out-of-bounds copy on saved Image3F buffer in release mode (or hitting a JXL_DASSERT in debug mode). The order in which the groups are processed depends on many factors, including the order in which the threads are scheduled when using multiple threads, and potentially the order of the groups in the file (not checked). Added a test to force the out-of-order situation in a simulated parallel runner that forces a random order on the tasks. The new test triggers the assert in debug mode, which is now fixed. Fixes libjxl#708.
When processing groups out of order with an image where the last group size is smaller than the needed border it was possible to attempt to load the right or bottom border from the next group when already processing the rightmost or bottom group respectively. This situation was causing an out-of-bounds copy on saved Image3F buffer in release mode (or hitting a JXL_DASSERT in debug mode). The order in which the groups are processed depends on many factors, including the order in which the threads are scheduled when using multiple threads, and potentially the order of the groups in the file (not checked). Added a test to force the out-of-order situation in a simulated parallel runner that forces a random order on the tasks. The new test triggers the assert in debug mode, which is now fixed. Fixes libjxl#708.
When processing groups out of order with an image where the last group size is smaller than the needed border it was possible to attempt to load the right or bottom border from the next group when already processing the rightmost or bottom group respectively. This situation was causing an out-of-bounds copy on saved Image3F buffer in release mode (or hitting a JXL_DASSERT in debug mode). The order in which the groups are processed depends on many factors, including the order in which the threads are scheduled when using multiple threads, and potentially the order of the groups in the file (not checked). Added a test to force the out-of-order situation in a simulated parallel runner that forces a random order on the tasks. The new test triggers the assert in debug mode, which is now fixed. Fixes libjxl#708.
When processing groups out of order with an image where the last group size is smaller than the needed border it was possible to attempt to load the right or bottom border from the next group when already processing the rightmost or bottom group respectively. This situation was causing an out-of-bounds copy on saved Image3F buffer in release mode (or hitting a JXL_DASSERT in debug mode). The order in which the groups are processed depends on many factors, including the order in which the threads are scheduled when using multiple threads, and potentially the order of the groups in the file (not checked). Added a test to force the out-of-order situation in a simulated parallel runner that forces a random order on the tasks. The new test triggers the assert in debug mode, which is now fixed. Fixes libjxl#708.
When processing groups out of order with an image where the last group size is smaller than the needed border it was possible to attempt to load the right or bottom border from the next group when already processing the rightmost or bottom group respectively. This situation was causing an out-of-bounds copy on saved Image3F buffer in release mode (or hitting a JXL_DASSERT in debug mode). The order in which the groups are processed depends on many factors, including the order in which the threads are scheduled when using multiple threads, and potentially the order of the groups in the file (not checked). Added a test to force the out-of-order situation in a simulated parallel runner that forces a random order on the tasks. The new test triggers the assert in debug mode, which is now fixed. Fixes #708.
When processing groups out of order with an image where the last group size is smaller than the needed border it was possible to attempt to load the right or bottom border from the next group when already processing the rightmost or bottom group respectively. This situation was causing an out-of-bounds copy on saved Image3F buffer in release mode (or hitting a JXL_DASSERT in debug mode). The order in which the groups are processed depends on many factors, including the order in which the threads are scheduled when using multiple threads, and potentially the order of the groups in the file (not checked). Added a test to force the out-of-order situation in a simulated parallel runner that forces a random order on the tasks. The new test triggers the assert in debug mode, which is now fixed. Fixes libjxl#708. (cherry picked from commit e649705) (cherry picked from PR libjxl#775)
|
Thanks @novomesk for the link. The green rectangle is in the source image too, so that's good. |
|
Note: this bug got assigned CVE-2021-22564 |
|
@novomesk Please let me know if you would like to be credited in the CVE description and how (name, company affiliation, etc). |
|
Thanks, no need to give credit. |
Hello,
This crash occurs when a Qt application decode more JXL files at the same time via my qt-jpegxl-image-plugin
During the crash I see following message:
/var/tmp/portage/media-libs/libjxl-9999/work/libjxl-9999/lib/jxl/image_ops.h:48: JXL_DASSERT: rect_from.IsInside(from)Here is a simple console application I am able to reproduce crash easily:
sources.zip
How to compile and run:
The application decodes bucuresti2.jxl file in two threads (0 - main thread, 1 - worker thread). Each thread have different instance of the plug-in and each plug-in create own ParallelRunner.
It may not crash during first iteration, but sooner or later it crashes. The output may run like this:
Sometime it crashes immediately:
When just one thread with plug-in is running at a time, there is no crash.
The text was updated successfully, but these errors were encountered: