You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An alternate solution would involve upstreaming this fix to embree I suppose, since their buffer check calculation dereferencing at 24 bytes instead of 16 is the actual cause.. (due to the size of int* changing on x86_64 vs x86_32)
jamie-pate
changed the title
AddressSanitizer: heap-buffer-overflow caused by embree buffer check miscalculation
AddressSanitizer: heap-buffer-overflow caused by embree buffer padding added using resize() instead of reserve()
Jul 22, 2024
Fixesgodotengine#94548
Use reserve() instead of resize() when padding the buffer passed to
embree, otherwise it will look past the end of the buffer since we pass
the size() to rtcSetSharedGeometryBuffer and it dereferences
`(int*)getPtr(size()-1) + 3`
could cause a segfault if `capacity < size + 12`(bytes)
When the address sanitizer is enabled it triggers an assertion
/*! checks padding to 16 byte check, fails hard */
__forceinline void checkPadding16() const
{
if (ptr_ofs && num)
volatile int MAYBE_UNUSED w = *((int*)getPtr(size()-1)+3); //
FIXME: is failing hard avoidable?
}
Tested versions
Reproducible in current HEAD: ff8a278
System information
Godot Engine v4.3.beta.custom_build.eb5f1299b (2024-07-19 02:22:03 UTC) - https://godotengine.org Vulkan 1.3.242 - Forward+ - Using Device #2: NVIDIA - NVIDIA GeForce RTX 3050 Laptop GPU
Issue description
Steps to reproduce
Enable asan and run a scene that uses occlusion culling? It only happens under certain conditions, even with asan enabled.
Minimal reproduction project (MRP)
asan-embree-output.txt
The text was updated successfully, but these errors were encountered: