From nobody Tue Feb 10 05:39:47 2026 Received: from mail-244123.protonmail.ch (mail-244123.protonmail.ch [109.224.244.123]) (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 3B8D244B682 for ; Tue, 20 Jan 2026 14:42:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.123 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768920131; cv=none; b=m98dHZc/62dY3zwdRSJBAF1ddqARawFnutk/ACRFMja+kTcacb0YgpCM8szeSCW66ZpmjywU3aBBrYsZtangTX8o+rR/HKtCe8bTC1qHdfMN03/plHO7siu4T7gJ8Wu5KK3cE1W7N/yEpu+GIeAcFwirNvs6odo3cSSQYaIeTkI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768920131; c=relaxed/simple; bh=qjc2vllS0+S0LJ+OOyTX2AcUSLOQUqm9LH2dXvUTuIs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TXFFc6Ccemtk6SguF0AdKRPUhKCsGa5hSq7HdAXbJyN6CbTMmt5mRUGf4vRXL9CzU+mTdGmt0cnTQ5N6v0ylyvsV3K9OBXSCowa9RXTZjTj2/aoBuRT4+wWHgyzT2e4LGJ51jINF2Y888jDPPlxfBMHpQ6wLaANjtzowtBF7lXg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=GXk8NTC/; arc=none smtp.client-ip=109.224.244.123 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="GXk8NTC/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1768920122; x=1769179322; bh=HyJMF4tS0EaCDrmBBe9rDMr7drYF7nWZ6FqPd4g05C4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=GXk8NTC/vxo3G8uf477qQVoZj4cJjhpsrGw8JNeqdObVWGhTasRgaor3JiqNsxhTI 8OC5y7H4EXosumKR0L/gqVoqady1kvcDOpflkiU1E8k1vhs1yh1kr4herfrsoJocXD 7JTLcjFh46v8xcTqpU33l2z7RV7bRwkVDK+JAPQecZaZEoAmWS+X72Xuo/m8uNQ10O v1lOeDzc531Y6segk4vEHFtqU8YEmMU23GiGksmzzYtE8zi2STI1vz8E8j9Ay+MXm4 Deckhz1ZHiK5P7N/Tqb2OW/8AkHQDb9xYjW1+kAz5qcqFmGHENA3OJAQ+8wr1rn+a/ mZ+6887cp91Jw== Date: Tue, 20 Jan 2026 14:42:01 +0000 To: Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" From: Maciej Wieczor-Retman Cc: m.wieczorretman@pm.me, Maciej Wieczor-Retman , linux-kernel@vger.kernel.org Subject: [PATCH v9 09/13] x86/mm: Reset tags in a canonical address helper call Message-ID: <23d87c37c97fd995a10297f8cc33ae2fa569f26d.1768845098.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 2b7246ae1262d4b6efe6ed8daa17e437f4a9a11c Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman For an address to be canonical it has to have its top bits equal to each other. The number of bits depends on the paging level and whether they're supposed to be ones or zeroes depends on whether the address points to kernel or user space. With Linear Address Masking (LAM) enabled, the definition of linear address canonicality is modified. Not all of the previously required bits need to be equal, only the first and last from the previously equal bitmask. So for example a 5-level paging kernel address needs to have bits [63] and [56] set. __is_canonical_address() helper can cause issues when met with tagged pointers that expect the loosened canonicality checks. The function itself shouldn't be made LAM-aware since for example in KVM, where it's used extensively - it's not practical to deal with differences between host and guest which might want a different LAM state. Also by the time __is_canonical_address() is invoked KVM has already done any necessary LAM unmasking. Reset tags in the address argument of __is_canonical_address() located in copy_from_kernel_nofault_allowed() which is the only function causing problems. Signed-off-by: Maciej Wieczor-Retman --- Changelog v9: - Redo the patch to not break KVM. - Remove Alexander's acked-by tag. Changelog v7: - Add Alexander's acked-by tag. - Add parentheses around vaddr_bits as suggested by checkpatch. - Apply the bitmasks to the __canonical_address() function which is used in kvm code. Changelog v6: - Use bitmasks to check both kernel and userspace addresses in the __is_canonical_address() (Dave Hansen and Samuel Holland). Changelog v4: - Add patch to the series. arch/x86/mm/maccess.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/maccess.c b/arch/x86/mm/maccess.c index 42115ac079cf..dbaf70bdc383 100644 --- a/arch/x86/mm/maccess.c +++ b/arch/x86/mm/maccess.c @@ -33,7 +33,7 @@ bool copy_from_kernel_nofault_allowed(const void *unsafe_= src, size_t size) if (!boot_cpu_data.x86_virt_bits) return true; =20 - return __is_canonical_address(vaddr, boot_cpu_data.x86_virt_bits); + return __is_canonical_address(__tag_reset(vaddr), boot_cpu_data.x86_virt_= bits); } #else bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size) --=20 2.52.0