Check for SIG_IGN and SIG_DFL before calling previous signal handler - #132900
Conversation
macOS doesn't clear sa_flags when calling execve. When dotnet is started from a process that sets a signal handler, the handler is cleared, but not the sa_flags. When the runtime gets a signal from an external source, it sees a stale SA_SIGINGO and tries to call the previous signal handler, but the pointer is set to SIG_IGN or SIG_DFL, which causes a crash. This change checks for those values before calling the previous signal handler. Add a regression test for the issue.
|
Azure Pipelines: Successfully started running 4 pipeline(s). 12 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
|
Tagging subscribers to this area: @agocke |
There was a problem hiding this comment.
Pull request overview
This PR hardens CoreCLR and NativeAOT activation-signal chaining by ensuring the runtime does not attempt to call a previous signal “handler” when the saved disposition is actually SIG_DFL or SIG_IGN, even if SA_SIGINFO is set (a state observed on macOS across execve). It also adds a macOS-only regression test that reproduces the inherited SA_SIGINFO + default/ignored disposition scenario and validates the runtime remains stable when an external SIGUSR1 arrives.
Changes:
- CoreCLR: gate chaining to the saved activation signal disposition behind
IsSigDfl/IsSigIgnchecks before calling eithersa_sigactionorsa_handler. - NativeAOT: apply the same
SIG_DFL/SIG_IGNguard to activation handler chaining whenSA_SIGINFOis set. - Tests: add a macOS-only regression test that installs an
SA_SIGINFOhandler,execvs into the .NET process, then triggers an externalSIGUSR1to exercise the chaining path.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/coreclr/pal/src/exception/signal.cpp | Prevents calling the previous activation handler when it’s SIG_DFL/SIG_IGN, regardless of stale SA_SIGINFO. |
| src/coreclr/nativeaot/Runtime/unix/PalUnix.cpp | Mirrors the same SIG_DFL/SIG_IGN guard for NativeAOT’s activation handler chaining. |
| src/tests/Regressions/coreclr/GitHub_132581/test132581.csproj | Adds a macOS-only, process-isolated regression test project with a native CMake dependency. |
| src/tests/Regressions/coreclr/GitHub_132581/test132581.cs | Managed test that execvs after installing the signal handler and then triggers an external SIGUSR1. |
| src/tests/Regressions/coreclr/GitHub_132581/nativetest132581.cpp | Native helper to install the SA_SIGINFO handler + execv, and to send SIGUSR1 from a forked child. |
| src/tests/Regressions/coreclr/GitHub_132581/CMakeLists.txt | Builds/installs the native helper library on macOS only. |
Clarify why the test is RequiresProcessIsolation. Add more descriptive method / class names to test code.
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
|
/ba-g Failures are an unrelated QUIC failure and #132947 |
|
/backport to release/11.0-rc1 |
|
Started backporting to |
|
/backport to release/10.0 |
|
Started backporting to |
…signal handler (#133177) Backport of #132900 to release/10.0 /cc @jtschuster ## Customer Impact - [X] Customer reported - [ ] Found internally macOS doesn't clear sa_flags when calling execve. When dotnet is started from a process that sets a signal handler, the handler is cleared, but not the sa_flags. When the runtime gets a signal from an external source, it sees a stale SA_SIGINGO and tries to call the previous signal handler, but the pointer is set to SIG_IGN or SIG_DFL, which causes a segmentation fault and crashes the process. This change checks for those values before calling the previous signal handler. Also adds a regression test for the issue. ## Regression - [ ] Yes - [X] No ## Testing The issue was reproduced in a regression test that was added to coreclr tests. The test fails without the fix and passes with it. ## Risk Low. The actual source change is small and targeted. Co-authored-by: Jackson Schuster <36744439+jtschuster@users.noreply.github.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com>
macOS doesn't clear sa_flags when calling execve. When dotnet is started from a process that sets a signal handler, the handler is cleared, but not the sa_flags. When the runtime gets a signal from an external source, it sees a stale SA_SIGINGO and tries to call the previous signal handler, but the pointer is set to SIG_IGN or SIG_DFL, which causes a crash. This change checks for those values before calling the previous signal handler. Also adds a regression test for the issue.
Fixes #132581