Re: [PATCH] rseq: don't promote transient TLS faults to SIGSEGV

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Jun 08, 2026 at 10:15:53AM +0800, Yuanhe Shu wrote:
> On return to user space the rseq slow path writes the new cpu_id /
> mm_cid into the user-space rseq TLS. rseq_update_usr() already
> classifies its failures in rseq_event::fatal: the flag is set only
> when corrupt user data is positively identified (e.g. a bad rseq_cs
> signature or an out-of-bounds abort IP) and stays clear when the
> access merely hit an unresolved page fault.
> 
> rseq_slowpath_update_usr() ignores that and calls force_sig(SIGSEGV)
> on any failure, so a transient page fault on a still-registered rseq
> area becomes a fatal SIGSEGV. This is reachable since glibc >= 2.35
> registers rseq for every thread by default: a memcg OOM victim can die
> of SIGSEGV (si_code=SI_KERNEL, si_addr=NULL) shortly after fork,
> before returning to user space, because the CoW of the inherited TLS
> page cannot be charged to the OOM-locked memcg and the rseq write
> faults.
> 
> With oom_score_adj=-1000 the OOM killer finds no killable task, so the
> rseq SIGSEGV is the sole outcome; otherwise the rseq SIGSEGV can be
> delivered before the OOM killer queues SIGKILL, and the process exits
> 139 instead of 137, breaking OOMKilled detection in container
> runtimes. LTP mm/oom03 and mm/oom05 reproduce it on v7.1-rc6+, and a
> strace A/B with glibc.pthread.rseq as the sole variable shows the
> SIGSEGV only when rseq is registered.
> 
> Only raise SIGSEGV when rseq_event::fatal is set. A non-fatal fault
> leaves the cached IDs untouched and is retried on a later return to
> user; a genuinely unmapped area keeps faulting and user space takes
> SIGSEGV through its own access. All corruption and ROP-hardening
> checks keep their SIGSEGV.

But this will return to userspace with invalid (not updated) rseq
values. This can lead to data corruption.

If we cannot write new rseq values on return to userspace, we must not
return -- it really is that simple.