Host environment - Operating system: Ubuntu 24.04 (WSL2) - OS/kernel version: Linux 6.6.87.2-microsoft-standard-WSL2 - Architecture: x86_64 - QEMU flavor: qemu-system-x86_64 - QEMU version: master at 81ce3a87737aa50716c42db8886082d12783e0a1 (11.1.50), built from source with `--target-list=x86_64-softmmu --enable-seccomp --disable-docs` against libseccomp 2.5.5. Also observed with 8.2.2 (Ubuntu package 1:8.2.2+ds-0ubuntu1.18). system/qemu-seccomp.c is byte-identical on master and in v11.1.1. - QEMU command line: ``` ./build/qemu-system-x86_64 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -machine none -accel tcg -nodefaults -display none -monitor none -serial none -S ``` (run as an unprivileged user) Emulated/Virtualized environment - Operating system: none (-machine none, -S) - OS/kernel version: n/a - Architecture: n/a Description of problem This was found with automated tooling: I captured the seccomp filter that QEMU installed, analysed it with an automated checker, and compared it with system/qemu-seccomp.c. An AI assistant helped prepare this report; I checked the source lines and the observed values myself. The spawn set in system/qemu-seccomp.c has three entries without an action field: ```c /* system/qemu-seccomp.c:251-255 (master, v11.1.1 and 8.2.2) */ #ifdef __SNR_execveat { SCMP_SYS(execveat), QEMU_SECCOMP_SET_SPAWN }, #endif { SCMP_SYS(setns), QEMU_SECCOMP_SET_SPAWN }, { SCMP_SYS(unshare), QEMU_SECCOMP_SET_SPAWN }, ``` The omitted `action` member of `struct QemuSeccompSyscall` (line 41) is zero-initialised, and 0 is `SCMP_ACT_KILL_THREAD` in libseccomp. `qemu_seccomp_update_action()` (line 279) only rewrites `SCMP_ACT_TRAP`, so these three calls kill only the calling thread. The rest of the spawn set behaves differently. On master, fork, vfork, execve and clone use `SCMP_ACT_ERRNO(EPERM)` (lines 216-223, since e79f8b8b). In 8.2.2 they used `SCMP_ACT_TRAP`, which QEMU turns into `SCMP_ACT_KILL_PROCESS` when the kernel supports it. Commit 46380571, which added the three entries, says "execveat is a new variant of execve so should be blocked just like execve already is". All three calls are still denied; only the action differs. On master, execve fails with EPERM while execveat kills the calling thread and leaves the rest of the process running. Steps to reproduce 1. Start the command line above as an unprivileged user. 2. Read the installed filter with PTRACE_SECCOMP_GET_FILTER (needs CAP_SYS_ADMIN; I used a small ptrace-based dumper run as root). 3. Evaluate the filter for x86_64 system calls 322 (execveat), 308 (setns), 272 (unshare), and 57, 58, 59 (fork, vfork, execve). Observed on master (81ce3a87): 322, 308 and 272 return 0x00000000 (SECCOMP_RET_KILL_THREAD); 57, 58 and 59 return 0x00050001 (SECCOMP_RET_ERRNO with EPERM). Both QEMU threads hold the same filter (129 instructions). Observed with 8.2.2: 322, 308 and 272 return 0x00000000 (SECCOMP_RET_KILL_THREAD); 57, 58 and 59 return 0x80000000 (SECCOMP_RET_KILL_PROCESS). Expected: execveat, setns and unshare get the same action as execve (on master, `SCMP_ACT_ERRNO(EPERM)`). Additional information Reproduced on upstream master at 81ce3a87737aa50716c42db8886082d12783e0a1 (built from source, x86_64 host, Linux 6.6.87.2-microsoft-standard-WSL2), with the values above; the first observation was on the Ubuntu 8.2.2 build. `seccomp-tools emu` gives the same actions for the six numbers. A possible change (not tested) is to give the three entries an explicit action, matching the rest of the set on master: ```c { SCMP_SYS(execveat), QEMU_SECCOMP_SET_SPAWN, 0, NULL, SCMP_ACT_ERRNO(EPERM) }, ``` and likewise for setns and unshare.