From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=202.12.124.138 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793060026; b=oaytqK4Wqt/Hn0vy+D46BIGA4AKCd+kahqMcYsVrHzGNV8AA9ZKl4R+imUpEI4HjJ7gC LkCEt7jANCiJNGQq9H/2FCojpRsS46+djjV/r6QQZrJh31JjSPXaO3vrOm6C86QVf8zaT r1J9LUAGKlWda4v/QrpXl8ZAZ3x1yrQAiCFQbXlSkGu93QASM/ZIHjPxIkr9WeREJDRSz 1KrCj3BJioNEETl+jd3oXn3S6hjxKAc25Lgc8lkUwZUU4cflzUQzrRf8HbNeVK+ll61MO nucZTShmcHjp7jIiCKiOhFw9pnxL0seu4eKXb/UyxnS2u2jRB/8oecHKn68FW/hqwIw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793060026; h=DMARC-Filter:Received:Received:DKIM-Signature:DKIM-Signature: X-DKIM2-Info:DKIM2-Signature:X-DKIM2-Info:Message-Instance: X-ME-Sender:X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID:Received:X-Mailer: MIME-Version:X-ThreadId:Date:From:To:Cc:Message-Id:In-Reply-To: References:Subject:Content-Type:Content-Transfer-Encoding; bh=si+Qhande5UvxFya2tFMhl+nVzGoE+GcsU0vRngX6G8=; b=vI54qwiH848EXnd1HcAm25MkjeK9j/jPyLVPJxtJ4h7vjth16JZJklsbp/dCVF1M7Nya 98FCRdQ3xjMafAGKAhXqBedvWQoxnsZW7s6jkUsQQRomMik5qxXUoHuftPf4KIcGUkymy aj1ctiCxNH+hel0dSsW5qtYKtjIs4lpJ8pUgta4jLb/KuEQmFb0Lr9cXLj1/ewuJf7h6S ovwxIEhTq7GG+QL4UMRiFB2C+9kUQ2TMj76fMinO3mrE1V+Miwyk5qFLM0a8eAxAOyd86 iGrGbkmrMLtshaI31BSdsPVRimIN1UgyhVpKMGKDsVhdMfzjVhcwJZysX9QLKVj7pNw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass header.d=arndb.de header.i=@arndb.de header.a=rsa-sha256 header.s=fm2 header.b=U3YGvdOt; dkim=pass header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=sNtb+bIv; arc=none smtp.remote-ip=202.12.124.138 Received: from flow-b3-smtp.messagingengine.com (flow-b3-smtp.messagingengine.com [202.12.124.138]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15930606A31B for ; Tue, 27 Oct 2026 00:13:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 15930606A31B Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=arndb.de header.i=@arndb.de header.a=rsa-sha256 header.s=fm2 header.b=U3YGvdOt; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=sNtb+bIv Received: from ams-compute-02.internal (ams-compute-02.internal [10.64.2.62]) by mailflow.stl.internal (Postfix) with ESMTP id 37C1A130202A for ; Mon, 26 Oct 2026 20:13:45 -0400 (EDT) Received: from ams-imap-03 ([10.64.2.23]) by ams-compute-02.internal (MEProxy); Mon, 26 Oct 2026 20:13:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1793060001; x=1793067201; bh=si+Qhande5UvxFya2tFMhl+nVzGoE+GcsU0vRngX6G8=; b= U3YGvdOtK5z0MLENZikfRWb/SLS3tN5q2KIlnncV8n8B6q/88GUIqRcHk/vGydtQ FS8sX9A1oRc3mRQPJMpF50WBg9qz94gDLC3+879cQZLNq1dxKLVBYjC/iOaTUChX mxYIwZLx1N3S7bbCZ/mImfn8wbd38nHV7hIgmF7vOKzU3+YYZrTQArEcc9rh+B/b KMdlqf5SKzL/f6s1EDnpY7XZ8W3nVEZg2L4msxlrfAqv/Jk0j7ZUlk/GsDSjkXPc ldA/XX4CvvPyKEcROFVx1tYb/KKG9fiNGXG9DUyjX7qxlOooitBLu4KPvsZBp7i9 9oEthDoRglV3rZfQE2aOZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1793060001; x= 1793067201; bh=si+Qhande5UvxFya2tFMhl+nVzGoE+GcsU0vRngX6G8=; b=s Ntb+bIvyt+finyiKcLyWraqD04yZyKS+0SUAaPYjEqXDnBV6zHgtFQ/8TfAY9oC2 NDiZXZWH0JHbhKyfa1dHcOfE0J4IpkbiAbjxrRL6Y92l1UGmObDGPnVKe7qP6YNt ST33rmDlLN6L8h6ZJEuWP90+wHD72V6+GnQYLlAgKBpi3+n3Tgh5LXp1sVOi4boh Bf6krYfz26TvqByg1xmWAI/FLJ4XaWMrrOUl2SAGfnYbLBUMdXBTuQqeXeSFgFhJ 3u/qloOapbu5S9e4vggtczW5heu5UykY3T8a2TZe7BZh1Nhjsya/HZaj/yXAM/kO TVxuIgUxJs7lnyHSGRSHA== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-07; repo=github.com/dkim2wg/interop; date=2026-10-18; sw=lmtpprox; action=sign d=arndb.de a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1793060001; d=arndb.de; mf=PGFybmRAYXJuZGIuZGU+; rt=PGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+; s=fm2:rsa-sha256:OdVmdRHqpoAS4P4P8eH5a2opEdzcS5nai64vjdYwZQRhfFM 5sd0pMtcPPTQVbWpB4nj9LIb0UwGk91b/aAg6eQqLWCPqVvD6kmnISjFaxfRiMVh 3KFcTaGYQCqTaY2//w8Tau3oOFvz+vTPqQeoczOg4gcwitTLERyojwB7HXqlxtCB vRtlxhx3ngeHUpVftw9r4jlmx1BwVNk6/ilostl3C5tr4FmxtI1vw8TJt7qXgoxF J1YLu3xBO6wzYjhmQRTJcVhMib7pCoIkrNIAw+On0FHKftDyCHfAlEZjf87kzJLo d62Y6gV6WTVHX4C6RSbF+lccLWx7U9grhARmpMQ==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-07; repo=github.com/dkim2wg/interop; date=2026-10-18; sw=lmtpprox; action=mi-m=1; hc=12; hn=cc,content-transfer-encoding,content-type,date,feedback-id, from,in-reply-to,message-id,mime-version,references,subject,to; Message-Instance: m=1; h=sha256:HO8bCNZuevoE55ZZzGJNSZMW2blajER/wEIsZJ9pK+U=:caeGQziho4FRHDY3cNygzudu2C/MJTIFaWIByauHPSA=; X-ME-Sender: X-ME-Proxy-Cause: dmFkZTEkf/YaqXBD6OkPCTBsCAQbPu2YW9sbt7UK3+UhRfBeofSSrl6hJkJHf9dF0rJg3N JfESDt4DvGRtzl+GmwBe7qsV2Za2TtScaDpwb+1nPiSEC23L7O5/QDGDDHkkqePFksREHl XU5dvNKC1hdHByCH0NgqiobHBjKrbj9jbD1I59fEdgTH3JMsZ6ZfDuO/z1c68fjUXFLL2r J8hVDQMrH064UmFfogQ8Sz3DesWwtSvTSw63x8Z2kd6ltXcHMkLp3Ud6vNRQYsKU7hjmRl /dP3RtDx62S+ikAxBE3BB1G+xG8JEObZSy6tVfPtEaGsqzPsdEyV7tjpBYy5RPu8eU7BtS pv/NdncJ9PUvwVRDTUHemZZgQCYS4NTDfHPcBktTUdmOVeXMmbEO8J4RkdFLvOctoGnsjm MVxFXKbZLUEIAQ1qS8Q5E64WXtwtwZQLEOfzHiJJZqf8ZryZPcMBmzKQXQ0QwZaN8ISNoJ S/ftgSQ59xD5mN0KYsovSy7v5Z8EmqiU+uzfw84F4PDmfcqLkrFleRwPnXor2ZPToL7Wwl zTDxlH62iD2P8UDUZF6+tWzflaIgNhpxvWwWeDJ+xjJX2nrXZjEv7k2ySwKy1geKMzAXKF fXgvX+juI9JxqNHFvQYpFjKMgWBUIHvrzcyM5V1fLrWdFMQTCqVFLDiOYoUQ X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.ams.internal (Postfix, from userid 501) id 5628B32A0093; Mon, 26 Oct 2026 20:13:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: AUJ1OXWu3nCJ Date: Tue, 27 Oct 2026 01:12:50 +0100 From: "Arnd Bergmann" To: "James Houghton" , "Andrew Morton" , "Alexander Viro" Cc: "Thomas Gleixner" , "Peter Zijlstra" , "Kees Cook" , "David Hildenbrand (Red Hat)" , "Lorenzo Stoakes" , "Liam R. Howlett" , "Vlastimil Babka (SUSE)" , "Mike Rapoport" , "Suren Baghdasaryan" , "Michal Hocko" , "Sean Christopherson" , "Paolo Bonzini" , "Jim Mattson" , "Jens Axboe" , "Pavel Begunkov" , "James E . J . Bottomley" , "Martin K. Petersen" , "David Sterba" , "Chris Mason" , "Alexei Starovoitov" , "Daniel Borkmann" , "John Fastabend" , "Josh Poimboeuf" , "Steven Rostedt" , "Masami Hiramatsu" , "Mathieu Desnoyers" , "Ingo Molnar" , "Arnaldo Carvalho de Melo" , "Namhyung Kim" , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, kvm@vger.kernel.org, io-uring@vger.kernel.org, linux-scsi@vger.kernel.org, linux-btrfs@vger.kernel.org, bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Message-Id: <14f5f919-55bd-47c6-a1c8-6f1445cce733@app.fastmail.com> In-Reply-To: <20261026215226.3713941-1-jthoughton@google.com> References: <20261026215226.3713941-1-jthoughton@google.com> Subject: Re: [RFC PATCH 00/10] uaccess: Refuse and warn on user accesses when current->mm is NULL Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, Oct 26, 2026, at 22:52, James Houghton wrote: > > This series comes out of a set of bugs that were found in KVM where the > kernel can sometimes write to a random process's user memory[1]. The KVM > fixes at [1] are still required, even with this uaccess series, as noted > by Sean here[2] and below in this cover letter. The beginning of this > series includes fixes for similar bugs found through static analysis > with Claude Opus 5.5. I don't think any of these bugs are more severe > than the KVM bugs[1]. > > We hit one of the KVM bugs in production, and it was challenging to > debug. This series makes such bugs, where the kernel is doing uaccess > without an mm, much more obvious. Nice work! > Such an access does not reliably fail. The user portion of the address > space belongs to whatever mm happens to be lazily loaded, if any. If > the access faults, the fault handler refuses to handle it and the copy > fails, but if the page is already mapped, the access silently reads or > writes another task's memory. This sounds like the problem depends a lot on the architecture, and to what degree they implement lazy mm switching. If an architecture makes all user pointers invalid for a kernel thread, this does not actually happen, right? E.g. on arm64 with CONFIG_ARM64_SW_TTBR0_PAN, the page table base for the current process is only set in user_access_begin() and would not point to any task here. Without ttbr0_pan, it should be covered by cpu_set_reserved_ttbr0() turning off all user space access for kernel threads. Should this perhaps be addressed in architecture specific code instead of in a common place? > == The New WARN == > > The rest of the series makes the generic uaccess helpers WARN_ON_ONCE() > and refuse the access when current->mm is NULL: > > - Patch 6 adds uaccess_should_fail(), which combines the existing > should_fail_usercopy() fault injection check with the NULL mm check, > and uses it in place of should_fail_usercopy(). This covers > copy_{to,from}_user() on all architectures (including the masked > user access paths, which never call access_ok()), the > __copy_{to,from}_user() variants used by KVM's guest memory > accessors, the user-backed iov_iter copy routines and > strncpy_from_user(). ... > The checks are deliberately limited to generic code. Accesses > implemented entirely by architectures (get_user(), put_user(), > clear_user(), and direct users of user_access_begin() or > masked_user_access_begin()) are not covered. Please let me know if the > new check should be placed elsewhere. I would think that user_access_begin() is a more natural place for the added checks, as this should be called exactly once for any function that accesses user space and also stays out of the way of the copy_from_kernel_nofault() etc. Arnd