-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Fix return address hijacking with CET #109074
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
Fix return address hijacking with CET #109074
Conversation
There is a problematic case when return address is hijacked while in a managed method that tail calls a GC write barrier and when CET is enabled. The write barrier code can change while the handler for the hijacked address is executed from the vectored exception handler. When the vectored exception handler then returns to the write barrier to re-execute the `ret` instruction that has triggered the vectored exception handler due to the main stack containing a different address than the shadow stack (now with the main stack fixed), the instruction may no longer be `ret` due to the change of the write barrier change. This change fixes it by setting the context to return to from the vectored exception handler to point to the caller and setting the Rsp and SSP to match that. That way, the write barrier code no longer matters.
Should the same change be made in naot to keep the two implementations in sync? runtime/src/coreclr/nativeaot/Runtime/EHHelpers.cpp Lines 551 to 556 in 061941a
|
NativeAOT does not require the fix, but it would be better if implementations match. LGTM, otherwise. Thanks!! |
I've just added commit with the nativeaot change. But I would like to know your opinion on where should the newly added |
That seems fine to me. That is where I'd put the helpers as well. |
/backport to release/9.0-staging |
Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11686309680 |
There is a problematic case when return address is hijacked while in a managed method that tail calls a GC write barrier and when CET is enabled. The write barrier code can change while the handler for the hijacked address is executed from the vectored exception handler. When the vectored exception handler then returns to the write barrier to re-execute the
ret
instruction that has triggered the vectored exception handler due to the main stack containing a different address than the shadow stack (now with the main stack fixed), the instruction may no longer beret
due to the change of the write barrier change.This change fixes it by setting the context to return to from the vectored exception handler to point to the caller and setting the Rsp and SSP to match that. That way, the write barrier code no longer matters.