runtime: sigaction calls from libraries result in segfault

[StaticRocket]

Go version

go version go1.25.0 linux/386

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GO386='sse2'
GOARCH='386'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m32 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2255728299=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='386'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/root/pamcheck/go.mod'
GOMODCACHE='/root/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/root/go'
GOPRIVATE=''
GOPROXY=''
GOROOT='/usr/lib/go'
GOSUMDB=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/root/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN=''
GOTOOLDIR='/usr/lib/go/pkg/tool/linux_386'
GOVCS=''
GOVERSION='go1.25.0'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Call any library function expecting to temporarily swap signal handlers temporarily. The following application can be used:

#include <string.h>
#include <signal.h>

int verify_bin(void) {
  struct sigaction newsa, oldsa;

  memset(&newsa, '\0', sizeof(newsa));
  newsa.sa_handler = SIG_DFL;

  sigaction(SIGCHLD, &newsa, &oldsa);
  sigaction(SIGCHLD, &oldsa, NULL);

  return 0;
}

Compile the above as a library, link it in a cgo application like the following:

package main

//#cgo CFLAGS: -Wall -std=c99
//#cgo LDFLAGS: -lsigdemo
//
//#include<sigdemo.h>
//
import "C"

import "syscall"

func main() {
	println("open")
	C.verify_bin()
	println("switch")
	syscall.Kill(syscall.Getpid(), syscall.SIGCHLD)
	println("done")
}

What did you see happen?

• A segmentation fault is generated when the switched signal handler is triggered.
• If the go runtime signal handler is never swapped back, then the application will not generate a segmentation fault.

What did you expect to see?

The application should not generate a segmentation fault. The following architectures are able to do the same thing without generating a fault:

• linux/arm
• linux/arm64
• linux/amd64

[StaticRocket]

If you are wondering what type of applications would need to do this, potentially anything linked against libpam, assuming the pam config is using the pam_unix.so module.

[gabyhelp]

Related Issues

• runtime: respect SA_RESETHAND when forwarding to non-Go signal handler #32659
• runtime: signalfd is not working after shared library compiled by cgo is loaded #55066
• Segfault when calling Go function from cgo signal handler #45499 (closed)
• runtime: signal handling: c-shared libraries intercepts SIGCHLD and crashes #13042 (closed)
• runtime: signal handling: sigfwd calls C handlers with improper alignment #17641 (closed)
• runtime: crash when receiving multiple signals on C threads on NetBSD #5885 (closed)
• runtime: unix: c-shared libraries segfault handler overrides the default handler #14899 (closed)
• runtime: cgo stuck because of go signal handler went into dead loop if pid=1 #59569
• runtime: program panics if receive other signal #21008 (closed)
• runtime: signal_amd64x.go:76 SIGINT on darwin/amd64 causes segfault under c-shared library #13034 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[prattmic]

cc @golang/runtime

[ianlancetaylor]

With GOARCH=386 the Go runtime sets signals with the SA_RESTORER flag set and the sa_restorer field set in the struct kernel_sigaction passed to the kernel.

The strace output of the C code looks like this:

[pid 3917143] rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, {sa_handler=0x80b7900, sa_mask=~[KILL STOP], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x80b7910}, 8) = 0
[pid 3917143] rt_sigaction(SIGCHLD, {sa_handler=0x80b7900, sa_mask=~[KILL STOP], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=NULL},  <unfinished ...>
[pid 3917143] <... rt_sigaction resumed>NULL, 8) = 0

Here we see that the first call to sigaction returns a kernel_sigaction with the SA_RESTORER flag and the sa_restorer field set. The second call to sigaction passes a kernel_sigaction with the SA_RESTORER flag set but the sa_restorer field set to NULL.

This is the cause of the segmentation violation. Since the SA_RESTORER flag is set the kernel arranges for the signal handler (which is the Go runtime function cgoSigtramp) to return to the value in the sa_restorer field. Thus the signal is delivered, the signal handler is called, and it returns to the address zero, causing a segmentation violation.

So the question is: why does the C code lose track of the sa_restorer field?

It turns out that the glibc code for sigaction simply ignores the sa_restorer field in the input. It sets sa_restorer in the kernel_sigaction field based on whether dl_sysinfo_dso is set. It also sets the SA_RESTORER flag in that case. But it does not clear the SA_RESTORER flag otherwise.

I can fix the example program by adding lines to the C code:

#define SA_RESTORER 0x04000000
  oldsa.sa_flags &= ~SA_RESTORER;

between the two calls to sigaction.

Fortunately we already have all the framework required for the fix: https://go.dev/cl/701375.

[gopherbot]

Change https://go.dev/cl/701375 mentions this issue: runtime: when using cgo on 386, call C sigaction function

[StaticRocket]

I can confirm that the above patch resolves the reported issue with sigaction.

Tested-by: Randolph Sapp <rs@ti.com>