google / google/gvisor

`posix_spawnp` with `POSIX_SPAWN_SETPGROUP` fails with EPERM under ptrace platform

Open
#13,556 2 comments 0 reactions 1 assignee Claimed by @MrEx3cut0r View on GitHub
type: bug
Dominant language
Go
Stars
19.3k
Forks
2k
Avg merge
3d 5h
Merged PRs (30d)
264

Description

### Description

While running syzkaller against gVisor's ptrace platform, the syzkaller executor crashes with posix_spawnp returning EPERM ("Operation not permitted"). The failure originates from posix_spawnp being called with the POSIX_SPAWN_SETPGROUP flag, which internally triggers `setpgid(0, 0)` in the spawned child. Under gVisor ptrace, this setpgid call is rejected with EPERM.
Per `setpgid(2)`, EPERM is returned when the calling process is a session leader or when the target process is not in the caller's session. In this scenario the child is a fresh non-session-leader process calling `setpgid(0, 0)`, which should be permitted.

**Expected behavior**: `setpgid(0, 0)` for a non-session-leader child should succeed, allowing `posix_spawnp` with `POSIX_SPAWN_SETPGROUP` to create a new process group.

**Actual behavior**: `setpgid` returns EPERM, causing `posix_spawnp` to fail and the executor to crash.

Related: https://github.com/google/syzkaller/issues/7478

### Steps to reproduce

Not reliably reproducible. Observed intermittently in syzkaller's ci-gvisor-ptrace-3 CI pipeline while the syzkaller executor repeatedly forks/restarts subprocesses with posix_spawnp using the POSIX_SPAWN_SETPGROUP flag (which internally triggers setpgid(0, 0) in the spawned child).

### runsc version

```shell
- gVisor version: 0.0.0, go1.26.3, amd64
- Platform: ptrace
- Args: [/syzkaller/managers/ci-gvisor-ptrace-3/current/image -root /syzkaller/managers/ci-gvisor-ptrace-3/workdir/gvisor_root -watchdog-action=panic -network=none -debug -debug-log=/dev/stderr -platform=ptrace -network=host -overlay2=all:self -net-raw -watchdog-action=panic debug -stacks --ps ci-gvisor-ptrace-3-0]
```

### docker version (if using docker)

```shell

```

### uname

_No response_

### kubectl (if using Kubernetes)

```shell

```

### repo state (if built from source)

_No response_

### runsc debug logs (if available)

```shell
SYZFAIL: posix_spawnp failed
D0605 02:48:18.876563 1 task_signals.go:216] [ 65517( 39): 65523( 44)] Signal 33: delivering to handler
D0605 02:48:18.876525 1 task_signals.go:475] [ 65517( 39): 65517( 39)] No task notified of signal 33
D0605 02:48:18.876599 1 task_signals.go:216] [ 65517( 39): 65518( 40)] Signal 33: delivering to handler
D0605 02:48:18.876719 1 task_signals.go:464] [ 65517( 39): 65517( 39)] Notified of signal 33
(errno 1: Operation not permitted)
D0605 02:48:18.877014 1 task_signals.go:175] [ 65517( 39): 65519( 41)] Restarting syscall 202: interrupted by signal 33
D0605 02:48:18.877054 1 task_signals.go:216] [ 65517( 39): 65519( 41)] Signal 33: delivering to handler
D0605 02:48:18.877022 1 task_signals.go:475] [ 65517( 39): 65517( 39)] No task notified of signal 33
D0605 02:48:18.877192 1 task_signals.go:216] [ 65517( 39): 65517( 39)] Signal 33: delivering to handler
D0605 02:48:18.878278 1 task_signals.go:475] [ 65517( 39): 65517( 39)] No task notified of signal 33
D0605 02:48:18.878437 1 task_exit.go:225] [ 10: 10] Transitioning from exit state TaskExitNone to TaskExitInitiated
D0605 02:48:18.878654 1 task_signals.go:464] [ 65348: 65348] Notified of signal 9
D0605 02:48:18.878699 1 task_signals.go:464] [ 65336: 65336] Notified of signal 9
D0605 02:48:18.878733 1 task_signals.go:464] [ 64881: 64881] Notified of signal 9
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.