Panic in TTY IOCTL TIOCSPGRP #11943
Description
Description
We are experiencing a panic in gVisor. The panic log is:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xa72e35]
goroutine 29198453 gp=0xc0339d4540 m=56 mp=0xc002900808 [running]:
panic({0x11dc220?, 0x30b9190?})
bazel-out/k8-opt/bin/external/io_bazel_rules_go/stdlib_/src/runtime/panic.go:811 +0x168 fp=0xc028e1f6e8 sp=0xc028e1f638 pc=0x478768
runtime.panicmem(...)
bazel-out/k8-opt/bin/external/io_bazel_rules_go/stdlib_/src/runtime/panic.go:262
runtime.sigpanic()
bazel-out/k8-opt/bin/external/io_bazel_rules_go/stdlib_/src/runtime/signal_unix.go:925 +0x359 fp=0xc028e1f748 sp=0xc028e1f6e8 pc=0x47b1b9
gvisor.dev/gvisor/pkg/sentry/kernel.(*ThreadGroup).SetForegroundProcessGroupID(0x0, {0x15fde60?, 0xc03c71d908?}, 0xc04fc80d80, 0x4fed)
pkg/sentry/kernel/thread_group.go:576 +0x1f5 fp=0xc028e1f868 sp=0xc028e1f748 pc=0xa72e35
gvisor.dev/gvisor/pkg/sentry/fsimpl/host.(*TTYFileDescription).Ioctl(0xc03f10a990, {0x15fde60, 0xc03c71d908}, {0x15f4cd8, 0xc01e440008}, 0x10, {{0xff}, {0x5410}, {0x7f9dcf7b468c}, {0x8}, ...})
pkg/sentry/fsimpl/host/tty.go:187 +0x714 fp=0xc028e1f9a0 sp=0xc028e1f868 pc=0xbb1474
gvisor.dev/gvisor/pkg/sentry/vfs.(*FileDescription).Ioctl(...)
pkg/sentry/vfs/file_description.go:715
gvisor.dev/gvisor/pkg/sentry/syscalls/linux.Ioctl(0xc03c71d908, 0x10, {{0xff}, {0x5410}, {0x7f9dcf7b468c}, {0x8}, {0x7f9dcf7b4720}, {0x5622c2655042}})
pkg/sentry/syscalls/linux/sys_file.go:284 +0x389 fp=0xc028e1fa78 sp=0xc028e1f9a0 pc=0xbe6d49
gvisor.dev/gvisor/pkg/sentry/kernel.(*Task).executeSyscall(0xc03c71d908, 0x10, {{0xff}, {0x5410}, {0x7f9dcf7b468c}, {0x8}, {0x7f9dcf7b4720}, {0x5622c2655042}})
pkg/sentry/kernel/task_syscall.go:143 +0x655 fp=0xc028e1fca8 sp=0xc028e1fa78 pc=0xa6d035
gvisor.dev/gvisor/pkg/sentry/kernel.(*Task).doSyscallInvoke(0xc03c71d908, 0x10, {{0xff}, {0x5410}, {0x7f9dcf7b468c}, {0x8}, {0x7f9dcf7b4720}, {0x5622c2655042}})
pkg/sentry/kernel/task_syscall.go:323 +0x45 fp=0xc028e1fd00 sp=0xc028e1fca8 pc=0xa6e185
gvisor.dev/gvisor/pkg/sentry/kernel.(*Task).doSyscallEnter(0xc03c71d908, 0x10, {{0xff}, {0x5410}, {0x7f9dcf7b468c}, {0x8}, {0x7f9dcf7b4720}, {0x5622c2655042}})
pkg/sentry/kernel/task_syscall.go:283 +0x65 fp=0xc028e1fd50 sp=0xc028e1fd00 pc=0xa6dea5
gvisor.dev/gvisor/pkg/sentry/kernel.(*Task).doSyscall(0xc02c6fdd90?)
pkg/sentry/kernel/task_syscall.go:258 +0x2a5 fp=0xc028e1fe28 sp=0xc028e1fd50 pc=0xa6dc25
gvisor.dev/gvisor/pkg/sentry/kernel.(*runApp).execute(0xc02e3271a8?, 0xc03c71d908)
pkg/sentry/kernel/task_run.go:269 +0xebc fp=0xc028e1ff30 sp=0xc028e1fe28 pc=0xa6377c
gvisor.dev/gvisor/pkg/sentry/kernel.(*Task).run(0xc03c71d908, 0x502b)
pkg/sentry/kernel/task_run.go:97 +0x214 fp=0xc028e1ffc0 sp=0xc028e1ff30 pc=0xa62254
gvisor.dev/gvisor/pkg/sentry/kernel.(*Task).Start.gowrap1()
pkg/sentry/kernel/task_start.go:412 +0x25 fp=0xc028e1ffe0 sp=0xc028e1ffc0 pc=0xa6ba85
runtime.goexit({})
src/runtime/asm_amd64.s:1700 +0x1 fp=0xc028e1ffe8 sp=0xc028e1ffe0 pc=0x481581
created by gvisor.dev/gvisor/pkg/sentry/kernel.(*Task).Start in goroutine 29198330
pkg/sentry/kernel/task_start.go:412 +0xc5
We have applied the following patch, which looks like it might have helped, but feels more like a bandage over the problem rather than an actual solution:
diff --git a/pkg/sentry/fsimpl/host/tty.go b/pkg/sentry/fsimpl/host/tty.go
index ce380b3d5..e46239bd4 100644
--- a/pkg/sentry/fsimpl/host/tty.go
+++ b/pkg/sentry/fsimpl/host/tty.go
@@ -164,6 +164,9 @@ func (t *TTYFileDescription) Ioctl(ctx context.Context, io usermem.IO, sysno uin
return 0, linuxerr.ENOTTY
}
+ if t.ThreadGroup() == nil {
+ return 0, linuxerr.ENOTTY
+ }
fgpg, err := t.ThreadGroup().ForegroundProcessGroup(t.TTY())
if err != nil {
return 0, err
@@ -184,6 +187,9 @@ func (t *TTYFileDescription) Ioctl(ctx context.Context, io usermem.IO, sysno uin
return 0, err
}
pgID := kernel.ProcessGroupID(pgIDP)
+ if t.ThreadGroup() == nil {
+ return 0, linuxerr.ENOTTY
+ }
if err := t.ThreadGroup().SetForegroundProcessGroupID(ctx, t.TTY(), pgID); err != nil {
return 0, err
}
Steps to reproduce
To recreate this spawn a pod with runsc:
apiVersion: apps/v1
kind: Deployment
metadata:
name: tty-crash
spec:
strategy:
type: Recreate
selector:
matchLabels:
app: tty-crash
template:
metadata:
labels:
app: tty-crash
spec:
containers:
- name: tty-crash
image: ubuntu:latest
resources: {}
command:
- sleep
- infinity
runtimeClassName: runsc
Once this is running, exec into the pod with the following command: kubectl exec -it $POD -- sh -c "(bash || ash || sh)".
Leave this running and then from another terminal window kill kubectl pkill kubectl.
This will close the exec session. If you try to re-exec immediately, you will be hit with a series of errors, and then Kubernetes events will report Pod sandbox changed, it will be killed and re-created.
This is observed with the following runsc config:
[runsc_config]
net-raw = "true"
systemd-cgroup = "true"
runsc version
`20250625.0` and `20250715.0`docker version (if using docker)
uname
6.12.35-061235-generic #202506271123 SMP PREEMPT_DYNAMIC Fri Jun 27 16:55:15 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
kubectl (if using Kubernetes)
`v1.32.4-gke.600`repo state (if built from source)
No response
runsc debug logs (if available)
https://storage.googleapis.com/nf-misc/runsc/tty-crash/debug.tar.gz
This includes the strace logs as well.