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=1793060028; b=f5nq5YcIgB1jrwaXKszHxAdXcKjUZvClWxog3hwdJIp9M3DrDPvxzlcYTXE9QteyYyRB nlOQVT7/vzSvKsx/RoC0UAM36CoZbkMsrH2Xi8d8k7l6vZZwsIrWvM0FbPK0wiLo+1mcp NKZm7ukO7Qu3AIrRjbsRsu3dVGve0mIPTgag0Ujf0Xia8oVddBJdmJPMmkM/a7svOMLyD bsLZIIyUjN81f2qQRabc1sQBejFeRfo0NlptVsQJkZMT3HtBQxW5k+smmTV4G1jNAGFhK DtKkPErWDoy2NcmvInbRg89QYWMizPc6IfgbxpZLfGgaG2RSgzDseIdRupMzsmgR02Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793060028; 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=qGWSHXeDxIMMFyI1xeM5XoXmmLewn9y4HT2dn6P9wDsWBL40ZrmHIx3ZsBZVTJ7MaQqZ ol3ZyIYUwk49J5z0fcifo9XFUYKsFX5oxNJ4ygReRzCx6gkGHyA3d8YyOpjdr0EROKmN+ Up6aZYI1UlIOAk/zDtZXfk51BBKzU7vDCqmMebvyazN3Y55eAje1zcIHGmIeJALKNXYBu GTNFp2NY4G6mF3j4MT4vpTMeiKUFIj4BJNvfuBT1d065gCTxQsDFOfXoJg6lV7lPymSme Kz2MqAn1auc/uYbUbitNu87XawQcxmmHr09tUddKsTGB+9dSYzZ2xHJq+ZdhIC3eWLA== 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 BAF09606A326 for ; Tue, 27 Oct 2026 00:13:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org BAF09606A326 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 11BF9130202A for ; Mon, 26 Oct 2026 20:13:46 -0400 (EDT) Received: from ams-imap-03 ([10.64.2.23]) by ams-compute-02.internal (MEProxy); Mon, 26 Oct 2026 20:13:47 -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=PGxpbnV4LXRyYWNlLWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+; s=fm2:rsa-sha256:GuRqkyvaJ5pGb4MFB97EjUGrGA12NkKlDm8cukhSKlqWnGR yUWlbpTifd9o2A5a4UdKp5ik7KZQM/5Obv6Qh7cdRvjIPPS8eCrL/TYGQyvv5fi/ o1cltL4l5FLc+4Di3AuYm4+UvbYeX9pKS5vfvmuEQCO0tnNx2C7goBhqQbZrA2bj r0MkrtspCZjYdCgTlNIcz6dB28brO9OOlMYVYyKZrxgfkGd1i2K9GAINL0hErwrP rIvLP7Z8p0w/nq0MSkht2xvVnFRljJpyFVZwT4Zg1kSiZkLgDcSO1cEzLBSsBvHb tXnbbjkE1zg9lpCyymjkmyRJutvMG7XJc6umYjQ==; 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-trace-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