Dear Maintainer,
virtiofsd crashes with SIGSYS (seccomp) on the first request after a
client connects, making any VM with a virtiofs share fail to start.
This has been 100% reproducible on my host, standalone, with no libvirt
involved.
virtiofsd accepts the vhost-user socket connection successfully, then
is killed by its own seccomp filter (SIGSYS) apparently while calling
getsockopt(2) (syscall 55) — likely a SO_PEERCRED check on the newly
accepted socket, immediately after "Client connected, servicing
requests".
REPRODUCTION
-------------
Terminal 1:
$ sudo /usr/libexec/virtiofsd --socket-path=/tmp/manual-vfsd.sock \
--shared-dir=/home/user/shares --log-level=debug
Terminal 2:
$ sudo qemu-system-x86_64 \
-machine q35 -m 2G \
-object memory-backend-memfd,id=mem,size=2G,share=on \
-numa node,memdev=mem \
-chardev socket,id=chr-vu-fs0,path=/tmp/manual-vfsd.sock \
-device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=shares \
-display none -serial mon:stdio
Result in Terminal 1:
[...] INFO virtiofsd] Waiting for vhost-user socket connection...
[...] INFO virtiofsd] Client connected, servicing requests
[...] ERROR virtiofsd::util] Child process terminated by signal 31
Result in Terminal 2:
qemu-system-x86_64: -device vhost-user-fs-pci,...: Failed to read
msg header. Read 0 instead of 12. Original request 0.
qemu-system-x86_64: -device vhost-user-fs-pci,...: vhost_backend_init
failed: Protocol error
KERNEL AUDIT LOG (seccomp)
---------------------------
Reproduced with --seccomp=log instead of the default enforcing mode
to confirm the exact syscall via kauditd, rather than only guessing
from the SIGSYS:
audit: type=1326 audit(1786353556.601:476): auid=1000 uid=0 gid=0
ses=4 subj=virtiofsd pid=120515 comm="virtiofsd-backe"
exe="/usr/libexec/virtiofsd" sig=31 arch=c000003e syscall=55
compat=0 ip=0x7f1be9b075ca code=0x80000000
syscall=55 on x86_64 is getsockopt.
With --seccomp=log the process survives and services requests normally, which
would point that the seccomp filter seems to be the actual blocker.
WORKAROUND
----------
Running with --seccomp=none avoids the crash entirely; the daemon
then services requests without issue. This is only being used as a
temporary unblock, not a real fix, since it disables the syscall
sandbox for the whole process.
WHAT DOES *NOT* APPEAR TO BE THE CAUSE
---------------------------------------
This was originally suspected to be a package regression, but according to
/var/log/dpkg.log and dpkg.log.1, I don't see any recent updates to the
packages I suspect could be involved (e.g. virtiofsd or libseccomp2)
- Kernel: running 7.1.6+deb14-amd64 since this morning's boot
(2026-08-10 07:38); the first crash occurred at 08:26, before
any package changes were made today, and 7.1.6 itself had already
been installed
- systemd, libvirt: no relevant entries in dpkg.log/dpkg.log.1 for
either package in the recent window (grep across both current and
rotated logs came up empty).
- Domain XML / libvirt config: <memoryBacking> with memfd + shared
access is present and correct; <filesystem> block is standard
(driver type='virtiofs', accessmode='passthrough'). No config
changes preceded the first crash.
The trigger appears to be environmental rather than a version
bump in any of the obvious candidate packages, although I am a bit lost on what
could be the change/cause.
Happy to gather more information (strace, additional kernel/glibc version
detail, etc.) on request.
Thanks,
Jonas.
Hi again,
Just in case it is useful, this is strace on the virtiofsd process:
sudo strace -f -p 124977
strace: Process 124977 attached with 2 threads
[pid 124978] epoll_wait(6 <unfinished ...>
[pid 124977] accept4(4, {sa_family=AF_UNIX}, [110 => 2], SOCK_CLOEXEC) = 11
[pid 124977] fcntl(11, F_DUPFD_CLOEXEC, 3) = 12
[pid 124977] mmap(NULL, 2101248, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f5564baa000
[pid 124977] madvise(0x7f5564baa000, 4096, MADV_GUARD_INSTALL) = 0
[pid 124977] rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0
[pid 124977]
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
child_tid=0x7f5564daa990, parent_tid=0x7f5564daa990, exit_signal=0,
stack=0x7f5564baa000, stack_size=0x1ffe00, tls=0x7f5564daa6c0} =>
{parent_tid=[3]}, 88) = 3
strace: Process 125168 attached
[pid 124977] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 125168] rseq({cpu_id_start=0, cpu_id=RSEQ_CPU_ID_UNINITIALIZED,
rseq_cs=NULL, flags=0, node_id=0, mm_cid=0, slice_ctrl={request=0,
granted=0, __reserved=0}, __reserved=0}, 33, 0, 0x53053053 <unfinished ...>
[pid 124977] write(2, "[2026-08-10T09:52:18Z INFO virt"..., 76 <unfinished
...>
[pid 125168] <... rseq resumed>) = 0
[pid 124977] <... write resumed>) = 76
[pid 125168] set_robust_list(0x7f5564daa9a0, 24 <unfinished ...>
[pid 124977] futex(0x7f5564daa990, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME,
3, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
[pid 125168] <... set_robust_list resumed>) = 0
[pid 125168] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 125168] prctl(PR_SET_NAME, "virtiofsd-backe"...) = 0
[pid 125168] mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7f5558000000
[pid 125168] munmap(0x7f555c000000, 67108864) = 0
[pid 125168] mprotect(0x7f5558000000, 135168, PROT_READ|PROT_WRITE) = 0
[pid 125168] sched_getaffinity(3, 32, [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15]) = 8
[pid 125168] gettid() = 3
[pid 125168] sigaltstack(NULL, {ss_sp=NULL, ss_flags=SS_DISABLE,
ss_size=0}) = 0
[pid 125168] mmap(NULL, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f556525f000
[pid 125168] mprotect(0x7f556525f000, 4096, PROT_NONE) = 0
[pid 125168] sigaltstack({ss_sp=0x7f5565260000, ss_flags=0, ss_size=8192},
NULL) = 0
[pid 125168] recvmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\0\0\0\1\0\0\0\0\0\0\0", iov_len=12}], msg_iovlen=1,
msg_controllen=0, msg_flags=0}, 0) = 12
[pid 125168] sendmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\0\0\0\5\0\0\0\10\0\0\0", iov_len=12},
{iov_base="\0\0\0t\1\0\0\0", iov_len=8}], msg_iovlen=2, msg_controllen=0,
msg_flags=0}, MSG_NOSIGNAL) = 20
[pid 125168] recvmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\17\0\0\0\1\0\0\0\0\0\0\0", iov_len=12}], msg_iovlen=1,
msg_controllen=0, msg_flags=0}, 0) = 12
[pid 125168] sendmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\17\0\0\0\5\0\0\0\10\0\0\0", iov_len=12},
{iov_base="+\244\10\0\0\0\0\0", iov_len=8}], msg_iovlen=2,
msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 20
[pid 125168] recvmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\20\0\0\0\1\0\0\0\10\0\0\0", iov_len=12}],
msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 12
[pid 125168] recvmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="+\244\10\0\0\0\0\0", iov_len=8}], msg_iovlen=1,
msg_controllen=0, msg_flags=0}, 0) = 8
[pid 125168] recvmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\21\0\0\0\1\0\0\0\0\0\0\0", iov_len=12}], msg_iovlen=1,
msg_controllen=0, msg_flags=0}, 0) = 12
[pid 125168] sendmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\21\0\0\0\5\0\0\0\10\0\0\0", iov_len=12},
{iov_base="\2\0\0\0\0\0\0\0", iov_len=8}], msg_iovlen=2, msg_controllen=0,
msg_flags=0}, MSG_NOSIGNAL) = 20
[pid 125168] recvmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="$\0\0\0\1\0\0\0\0\0\0\0", iov_len=12}], msg_iovlen=1,
msg_controllen=0, msg_flags=0}, 0) = 12
[pid 125168] sendmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="$\0\0\0\5\0\0\0\10\0\0\0", iov_len=12},
{iov_base="\375\1\0\0\0\0\0\0", iov_len=8}], msg_iovlen=2,
msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 20
[pid 125168] recvmsg(11, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\0\0\0\t\0\0\0\0\0\0\0", iov_len=12}], msg_iovlen=1,
msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS,
cmsg_data=[13]}], msg_controllen=24, msg_flags=0}, 0) = 12
[pid 125168] getsockopt(13, SOL_SOCKET, SO_DOMAIN, [0], [4]) = 55
[pid 124978] <... epoll_wait resumed> <unfinished ...>) = ?
[pid 124977] <... futex resumed>) = ?
[pid 125168] +++ killed by SIGSYS (core dumped) +++
[pid 124978] +++ killed by SIGSYS (core dumped) +++
Thanks!
I was able to reproduce this, reverting to 1.14.0-1 restored functionality for me, it appears to a regression introduced in -2.
Do you have kernel message(s) about the issue? It should report which syscall it disliked. The issue is most likely not due to virtiofsd itself but due to a recompile with more recent rustc or other crates, which now use more syscalls when virtiofsd originally planned for. I mean, it is very likely that a rebuild of 1.14.0-1 in current environment will also be buggy. Thanks, /mjt
Do you have kernel message(s) about the issue? It should report which syscall it disliked. The issue is most likely not due to virtiofsd itself but due to a recompile with more recent rustc or other crates, which now use more syscalls when virtiofsd originally planned for. I mean, it is very likely that a rebuild of 1.14.0-1 in current environment will also be buggy. Thanks, /mjt
We believe that the bug you reported is fixed in the latest version of rust-virtiofsd, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1144050@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Fabian Grünbichler <debian@fabian.gruenbichler.email> (supplier of updated rust-virtiofsd package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Thu, 13 Aug 2026 22:39:31 +0200 Source: rust-virtiofsd Architecture: source Version: 1.14.0-3 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers <pkg-rust-maintainers@alioth-lists.debian.net> Changed-By: Fabian Grünbichler <debian@fabian.gruenbichler.email> Closes: 1144050 Changes: rust-virtiofsd (1.14.0-3) unstable; urgency=medium . * Package virtiofsd 1.14.0 from crates.io using debcargo 2.8.4 * Update seccomp filter to match vhost 0.17 (Closes: #1144050) * Update mkosi autopkgtest to pick up unsigned systemd-boot efi files Checksums-Sha1: da2ddfc9474caac10f6963caba5133eaac0ac35d 3571 rust-virtiofsd_1.14.0-3.dsc 27c05bfec0503e9ada373c4a8c734321f5848cfa 8660 rust-virtiofsd_1.14.0-3.debian.tar.xz 3a75d71ca76cf2d9cb363fcaecc4006fc5ae0d36 7674 rust-virtiofsd_1.14.0-3_source.buildinfo Checksums-Sha256: 125c9496a74b99d65defa44cd101e80af37e50704899540dd30e601d71c2006a 3571 rust-virtiofsd_1.14.0-3.dsc fc1b57e9afc32cd09adff8d1d4bc55e67d983c04410d115e6349c74a3d53d664 8660 rust-virtiofsd_1.14.0-3.debian.tar.xz 868596ed9bd3e8387b4bd3c38e2a60657c684f307f39cb62abb8295a8cfa1cff 7674 rust-virtiofsd_1.14.0-3_source.buildinfo Files: a5ea27826ce653a7181431b53e15db0f 3571 otherosfs optional rust-virtiofsd_1.14.0-3.dsc 011bdbe3b566672632e50e8f639d1d63 8660 otherosfs optional rust-virtiofsd_1.14.0-3.debian.tar.xz a2a09614517b55fd14b9a163a8eda710 7674 otherosfs optional rust-virtiofsd_1.14.0-3_source.buildinfo -----BEGIN PGP SIGNATURE----- iQJVBAEBCgA/FiEEbdkGe7ToK0Amc9ppdh5TKjcTRTAFAmp+K40hHGRlYmlhbkBm YWJpYW4uZ3J1ZW5iaWNobGVyLmVtYWlsAAoJEHYeUyo3E0UwtEcQALt4tyBXYojX LLqZMWyefyHt5eTdEmVPboZ3Xh76hRsCZvISB2dqIY+xjuMzue4pbFf7SqG7v3g5 xwhSApnkmksW8YySsv2HNjJRAHZncPVPFMZ9wuHngqLm6EQbTufxgkQN1wzR96Sc GApKl/yeUC7iNHtceM3j4X/BH36YUMmDUt9eTlQWyLuIjfIZ42VIaTfWS0Tl9era PTL/AUdQW/+7/9qRWpEZ/6JJ1kKFIzb83UOVOacr1wkhZL9JRG/BB6gxPz9/DEP9 4wW2qaSfkFXLUbAsRaF7H9ALqECRccH6JPQMitOiOYi82JWrvv3gse+S57nDUxvf vwEDybnyYkHzr5WqZiYWlAwZw9JO47/z4h8tX3VVL6rUqQM4RVftkF2b+gQlhOYH OuVGQqGEMFvchiAQzkfJjnNPNPbFxsW6iiZXcAQ5qwKvHDqYWuuItO7m43Y1tWuk 9VhCqxuk9DXHMK0aYsTS9PEzZUoQUMFtQYTxLk7g0R/16QPEA3ABtgzzbiFVrq8C L2c4VkzaaDrMYcXGzFLcJy0Vu8HktKV/6FTZFZpN8mKWtPN72LwQi1DjSiqR1K1R H3FlzVck26SiNiu71Yws48LtvFsAEwRmBsVtag5oSO8AklPrk2iqsqxMkk6Q7+uE KvnMgfdWH/jWoVr6UmCjk9s47azPK2IM =P88t -----END PGP SIGNATURE-----