Qt in general is not thread safe, but QImage is supposed to be, see
https://doc.qt.io/qt-6/threads-modules.html
That is in fact the reason the code uses QImage rather than QPixmap even though QPixmap is faster to render. That said, there could well be a regression in newer Qt that breaks the supposed thread safety of QImage. See for example:
https://bugreports.qt.io/browse/QTBUG-90629
There are two QImage operations performed in the render thread, loading from data and resizing to create the thumbnail. If we don't trust QImage to be thread safe, probably best to move both into the GUI thread and just load the JPEG data into memory in the render thread. Or maybe have the render thread do resizing using PIL instead of Qt, that should cause the least loss of performance. PIL could output the thumbnail data in 32bpp format and it can be loaded into the QImage without copying using the QImage(uchar...) constructor. Or ditch QImage and use QPixmap (since we are now on the GUI thread) having PIL output in XPM or uncompressed PNG.
Needs some thought/experimentation.
Coming to your patch, its hard to know if it actually fixes the issue or just changes timing. If we have identified QImage not being thread safe as the culprit, then I would rather remove QImage completely from the render thread if that can be done performantly. I will look at it when I have some time, feel free to experiment further yourself if you want to, I will post here when I start working on it.