From: Cong Wang <xiyou.wangcong@gmail.com>
To: Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>,
linux-um@lists.infradead.org
Cc: Benjamin Berg <benjamin@sipsolutions.net>
Subject: [PATCH 0/7] um: skas: harden the seccomp userspace stub
Date: Fri, 19 Jun 2026 20:22:17 -0700 [thread overview]
Message-ID: <cover.1781925126.git.xiyou.wangcong@gmail.com> (raw)
From: Cong Wang <cwang@multikernel.io>
In the seccomp ("SECCOMP") userspace mode, each guest userspace process
runs in a stub under a seccomp filter and traps to the monitor (the UML
kernel) on every syscall. Two items on the stub.c "Known security issues"
list could not be addressed by the filter alone:
- a hijacked stub could mmap() arbitrary physmem offsets, which is an
intra-guest disclosure and, on this base (single physmem fd, no
kernel/user split), a host escape; and
- a hijacked stub could block SIGALRM via a crafted rt_sigreturn to
evade preemption and wedge the monitor indefinitely.
This series closes both:
1-2: route the stub's mmap() through a SECCOMP_RET_USER_NOTIF listener
owned by the monitor (no behavioural change yet).
3-4: validate each mmap() against the mm's page table -- allowed iff the
PTE already maps the requested frame with no more access than it
grants -- including out-of-batch mmaps a hijacked stub issues on
its own.
5: route and validate munmap() the same way (range-confined below
STUB_START).
6: add a watchdog thread that detects a stub which stops reporting
back (e.g. blocked SIGALRM) and SIGKILLs it, letting the monitor
recover via the existing teardown.
7: drop the now-resolved "Known security issues" note and refresh the
seccomp= help text.
After the series a hijacked stub is confined to the frames its own page
tables reference and can no longer reach arbitrary guest/host memory; one
that evades preemption is detected out of band and killed rather than
wedging the monitor.
Verified on UML (UP and 2-CPU SMP): boots and survives fork/exec storms
and heavy mmap/munmap churn with zero false denials or false kills; an
artificially SIGALRM-blocked busy loop is killed in ~5s and the monitor
recovers, while syscall-making processes are untouched. Each patch builds
and the series is bisectable.
---
Cong Wang (7):
um: skas: create a seccomp USER_NOTIF listener and hand it to the
monitor
um: skas: gate stub mmap() through the USER_NOTIF monitor
um: skas: validate stub mmap() against the guest page table
um: skas: handle out-of-batch stub mmap notifications
um: skas: validate stub munmap() against the guest address range
um: skas: kill stubs that block SIGALRM via a watchdog thread
um: skas: refresh stub security notes after closing the known issues
arch/um/include/shared/skas/mm_id.h | 1 +
arch/um/include/shared/skas/skas.h | 5 +
arch/um/kernel/skas/stub.c | 22 --
arch/um/kernel/skas/stub_exe.c | 19 +-
arch/um/kernel/skas/uaccess.c | 48 +++++
arch/um/os-Linux/skas/process.c | 315 ++++++++++++++++++++++++----
arch/um/os-Linux/start_up.c | 6 -
7 files changed, 344 insertions(+), 72 deletions(-)
base-commit: 1a3746ccbb0a97bed3c06ccde6b880013b1dddc1
--
2.43.0
next reply other threads:[~2026-06-20 3:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-20 3:22 Cong Wang [this message]
2026-06-20 3:22 ` [PATCH 1/7] um: skas: create a seccomp USER_NOTIF listener and hand it to the monitor Cong Wang
2026-06-20 3:22 ` [PATCH 2/7] um: skas: gate stub mmap() through the USER_NOTIF monitor Cong Wang
2026-06-20 3:22 ` [PATCH 3/7] um: skas: validate stub mmap() against the guest page table Cong Wang
2026-06-20 3:22 ` [PATCH 4/7] um: skas: handle out-of-batch stub mmap notifications Cong Wang
2026-06-20 3:22 ` [PATCH 5/7] um: skas: validate stub munmap() against the guest address range Cong Wang
2026-06-20 3:22 ` [PATCH 6/7] um: skas: kill stubs that block SIGALRM via a watchdog thread Cong Wang
2026-06-20 3:22 ` [PATCH 7/7] um: skas: refresh stub security notes after closing the known issues Cong Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1781925126.git.xiyou.wangcong@gmail.com \
--to=xiyou.wangcong@gmail.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=benjamin@sipsolutions.net \
--cc=johannes@sipsolutions.net \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox