`runsc`'s OCI seccomp converter silently discards per-rule `errnoRet`, breaking the standard clone3/glibc ENOSYS-fallback pattern

[ghaskins]

Description

Summary

runsc/specutils/seccomp/seccomp.go's conversion of an OCI LinuxSeccomp profile into
a BPF program reads a rule's Names, Action, and Args, but never reads
LinuxSeccompRule.ErrnoRet (nor LinuxSeccomp.DefaultErrnoRet). Every
SCMP_ACT_ERRNO result is hardcoded to EPERM:

// runsc/specutils/seccomp/seccomp.go
var (
	killThreadAction = seccomp.KillThread
	trapAction       = seccomp.Trap
	// runc always returns EPERM as the errorcode for SECCOMP_RET_ERRNO
	errnoAction = seccomp.ReturnError.Code(uint16(unix.EPERM))
	// runc always returns EPERM as the errorcode for SECCOMP_RET_TRACE
	traceAction = seccomp.Trace.Code(uint16(unix.EPERM))
	allowAction = seccomp.Allow
)

func convertAction(act specs.LinuxSeccompAction) (seccomp.Action, error) {
	switch act {
	...
	case specs.ActErrno:
		return errnoAction, nil   // always EPERM — errnoRet is never consulted
	...
}

convertRules() iterates s.Syscalls and reads only syscall.Action,
syscall.Args, and syscall.Names — syscall.ErrnoRet is never dereferenced anywhere
in the package. This is not a recent regression: the errnoAction/traceAction
constants date to the original commit adding OCI seccomp support
(dcd532e2e, 2020-09-16) and have never read a custom errno.

The mechanism to do this correctly already exists and works — SetReturnCode/.Code()
takes any uint16, and the Sentry honors an arbitrary errno for a filter an application
installs on itself via seccomp(SECCOMP_SET_MODE_FILTER, ...) — confirmed against
pkg/sentry/kernel/seccomp.go:

case linux.SECCOMP_RET_ERRNO:
	// "Results in the lower 16-bits of the return value being passed to
	// userland as the errno without executing the system call."
	t.Arch().SetReturn(-uintptr(result.Data()))

and exercised by the existing SeccompTest.RetErrnoReturnsErrno test, which asserts a
non-EPERM errno (ENOTNAM) round-trips correctly for a self-installed filter. The gap
is specifically in the OCI-spec → BPF converter, not in the Sentry's own seccomp
enforcement.

Why this matters: it breaks the standard clone3/glibc compatibility pattern

glibc ≥ 2.34 tries clone3 first in pthread_create (and other process/thread creation
paths) and falls back to legacy clone() only when clone3 fails with ENOSYS
specifically — any other errno is treated as a hard, unrecoverable failure
(sysdeps/unix/sysv/linux/clone-internal.c). Because clone3's single argument is an
opaque pointer to struct clone_args, classic seccomp-BPF cannot filter it by flag the
way clone()'s scalar flags argument can be filtered — so any OCI seccomp profile
that needs to block clone3(CLONE_NEWUSER) specifically (while leaving ordinary
thread/process creation working) has no choice but to block the syscall outright and
rely on ENOSYS to preserve the glibc fallback onto the still-filterable clone()
call.

This is exactly the fix Docker, containerd, and runc adopted when glibc 2.34 shipped
(runc's libcontainer/seccomp does honor per-rule errnoRet:
libseccomp.ActErrno.SetReturnCode(int16(*errnoRet))), and it is the standard,
widely-documented resolution for this entire class of compatibility issue. Because
runsc silently substitutes EPERM regardless of what the OCI profile actually
requests, any OCI seccomp profile written to follow this exact, standard pattern is
silently broken under runsc — the profile author's errnoRet: 38 (or any other
requested errno) is accepted without error and then discarded, with no signal that
anything went wrong until a modern-glibc guest tries to create a thread and gets
RuntimeError: can't start new thread instead.

Minimal reproducer

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_AARCH64"],
  "syscalls": [
    {"names": ["clone3"], "action": "SCMP_ACT_ERRNO", "errnoRet": 38}
  ]
}

Run any glibc ≥ 2.34 binary that creates a thread (e.g.
python3 -c "import threading; threading.Thread(target=lambda: None).start()") inside a
runsc sandbox with this profile applied via --oci-seccomp. Expected: clone3 fails
with ENOSYS (errno 38), glibc falls back to clone(), the thread is created
successfully. Actual: clone3 fails with EPERM (errno 1), which glibc treats as fatal;
thread creation fails.

(We can supply a full, runnable bundle/config.json if useful — happy to attach one.)

Suggested fix

In convertAction, thread the rule's ErrnoRet through to Code() instead of always
using the package-level errnoAction constant, mirroring runc's own handling:

func convertAction(act specs.LinuxSeccompAction, errnoRet *uint) (seccomp.Action, error) {
	switch act {
	...
	case specs.ActErrno:
		if errnoRet != nil {
			return seccomp.ReturnError.Code(uint16(*errnoRet)), nil
		}
		return errnoAction, nil // default EPERM, unchanged
	...
}

with the analogous change for BuildProgram's handling of s.DefaultAction /
s.DefaultErrnoRet. This looks like a small, low-risk, additive change — existing
profiles that don't set errnoRet are unaffected (falls through to today's EPERM
default), and the Code() API this would call already exists and is already exercised
by SeccompTest.RetErrnoReturnsErrno.

Relationship to existing issues

We found #12557 ("Support returning ENOSYS in seccomp rules") open and describing a
closely related problem — but that issue is specifically about gVisor's own
host-facing seccomp filters (the filter gVisor installs on itself), not the OCI-profile
path a sandboxed application runs under. This report is about the latter: the OCI
LinuxSeccomp.Syscalls[].ErrnoRet field, which is part of the runtime-spec that runsc
already accepts and validates the shape of, but doesn't act on. We think these are
related but distinct gaps, and #12557's fix would not, on its own, resolve this one.

Environment

• Reproduced against gVisor release-20260721.0 (the version we happened to have pinned);
  confirmed by reading runsc/specutils/seccomp/seccomp.go on master that the
  behavior is unchanged there as of this report.
• Confirmed clone3 is fully implemented in the Sentry's syscall table on this and
  later releases (not returning a native ENOSYS, which would otherwise have masked
  this gap) — this appears to have been the case since 21d66119b
  (release-20230814.0).

[jdymitarai]

Thanks for the detailed report and root-cause analysis @ghaskins!

I've opened PR #14731 to address this issue:

• Passes s.DefaultErrnoRet to convertAction in BuildProgram and syscall.ErrnoRet in convertRules.
• Constructs seccomp.ReturnError.Code(uint16(*errnoRet)) and seccomp.Trace.Code(uint16(*errnoRet)) whenever errnoRet != nil. If errnoRet is nil, it preserves the existing unix.EPERM default.
• Strictly validates that *errnoRet <= math.MaxUint16 (0..65535) for ActErrno and ActTrace, cleanly rejecting overflow without silent truncation or wrap.
• Maintains runc compatibility by ignoring unused errnoRet on non-DATA actions (ActAllow, ActKill, ActTrap), preventing startup failures on profiles with leftover generator metadata.
• Preserves rule independence: defaultErrnoRet applies only to unmatched syscalls under defaultAction, and does not leak onto per-syscall ActErrno rules with nil errnoRet (matching OCI and runc semantics).
• Adds comprehensive unit test coverage in seccomp_test.go covering the clone3 ENOSYS pattern, boundary values (0, 0x7fff, 0x8000, 0xffff), overflow rejections, and diagnostic error wrapping with syscall names.