-
-
Notifications
You must be signed in to change notification settings - Fork 21.6k
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 when attempting to decompress a 1x1 DXT1 compressed image #97862
Comments
I guess we need to do an early out if the texture dimensions are smaller than the block size |
1x1 DXT images shouldn't even be possible, I think it's an issue with how the compressed textures with non-multiple of 4 images retain their original dimensions, instead of their padded ones. In the decompressor we could round the resolution of the compressed images to the nearest upper multiple of 4, since that should fix most crashes. |
@kondoorsoft-trent would you be willing to upload the original SmallShip01.glb and SmallShip02.glb so that we can figure out how it got imported like that? |
Sure! Here are both, packed into a ZIP |
@fire This appears to be an issue with the glb importer as well. The embedded texture is 1x1; If we're importing these as DXT textures, they should be padded to 4x4. |
@lyuma argued a long time ago that 1x1 dxt are allowed via a smearing algorithm but I don’t have the log anymore |
Tested versions
godot master @ 5ccbf6e
System information
macOS 14.5.0, M2 Pro, Vulkan
Issue description
Attempting to call
decompress()
on a 1x1 DXT texture image (less than the 4x4 required) results in misaligned writes, which often lead to a heap buffer overflow. Sometimes you get lucky with your memory layout, but this is pretty reproducible for me.The culprit:
![image](https://private-user-images.githubusercontent.com/69168929/373910999-a3a7adb5-f3ef-45cf-bf61-ed022f564342.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzk0OTI0MTEsIm5iZiI6MTczOTQ5MjExMSwicGF0aCI6Ii82OTE2ODkyOS8zNzM5MTA5OTktYTNhN2FkYjUtZjNlZi00NWNmLWJmNjEtZWQwMjJmNTY0MzQyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjE0VDAwMTUxMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTA0NzdlODhhM2VlNmEzY2QxZGQzNDg1YTRjZTNjZGIwODU1NDVkZjU3ODdkYjMxMTJlNDFlZTRkZGY2NzZkZjkmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.5BVw8JtpIv2Uvwmqd8LFgv5dFkNrgGTJJdU_e8PR3Wc)
Happens right here, in bcdec.h:
Attached below is an ASAN log with the full stacktrace:
asan.log
Steps to reproduce
Open up the reproduction project in the editor; it will likely just crash immediately, though you may get lucky/unlucky depending on your memory layout.
Minimal reproduction project (MRP)
testdxtdecompress.zip
The text was updated successfully, but these errors were encountered: