From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B37B13AFCE9 for ; Mon, 8 Jun 2026 08:30:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780907430; cv=none; b=aShEtps6BWCiuU/fq6jk6um79h2Q9xkIHNiev4ypVfv9i7NhYGH+2Sg61FwlmpzcFSvi9b5GcnuGSd7uE19ggQDE5/VRLIwK6h5bUmd5f42Zqsj1u4ck7Tz8krgw3vsGCvWHPkj3UkEI5ZW3+Z4NmoSovqWxnJWZ02EtbujRJz4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780907430; c=relaxed/simple; bh=ChcHfS7y74W2YOhbQloI/xvHfLQkozZIClPHSIJ0Q1w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=O1U5pXDi1ORddixJw/ryOQ5PuEtMOkPjO+jL/h2Hqhh4eUNnYaCx2XKAgguiU9NEnUpkgBlijDBW+rZXGCJsDHkQXY0i+ASG88l9KWIgmjI3zkSBbK1uCrI3hzxRkfT6Wrl7TmDy1/sWfJ5/irPQsCYewfxR/krmClxymfNbmNg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=Uwby2Zop; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="Uwby2Zop" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=A6l2wtnp9mn5lhiuXyUP/O6YP8ucbSmAE2dMorHZG+0=; b=Uwby2Zopk15sM33mTwJYeCg5bt Qo0kMPbX+QDSJu4EeCBCw/4MgW9zMnB0mhFJju3xUikTepCoSk2jobHr4upqooKkW54DrID0waQcE usXCCL+h0yB+bL5BuEeLxLcBztw68FC5cS/Age1zzifUlEf+ry/cKSeoe8fr0vxMRi6nnWGH0dkDe IFJnw27vkPsFACDfZg6NckhaSw+f+w0DXqQfBKFynHsNdkoUQxkJADMb/nwpK8QJacREKHJdyDmaq su7gQpH9Nie8lrk5y5mtPQhvfoO+zvursZySw+ZMJ1/NzO0O6YTyjrWj9pkTM1HI3ppMOZknbjkJo mQFYynjw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wWVNI-0000000DK2X-0ydd; Mon, 08 Jun 2026 08:30:24 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 17EF530044E; Mon, 08 Jun 2026 10:29:24 +0200 (CEST) Date: Mon, 8 Jun 2026 10:29:23 +0200 From: Peter Zijlstra To: Yuanhe Shu Cc: Mathieu Desnoyers , "Paul E . McKenney" , Boqun Feng , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [PATCH] rseq: don't promote transient TLS faults to SIGSEGV Message-ID: <20260608082923.GC3102624@noisy.programming.kicks-ass.net> References: <20260608021553.1037128-1-xiangzao@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260608021553.1037128-1-xiangzao@linux.alibaba.com> 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.