From nobody Tue Feb 10 19:09:50 2026 Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch [79.135.106.30]) (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 4DA21347BD1 for ; Wed, 4 Feb 2026 19:20:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.30 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770232828; cv=none; b=VLYNSwMLrqgOHrpztiK1s3aluixjhbaWbDmf820yVSC7JAgxRRFi/1WchInrIP5JLWAodyZEDr9+tyiVb9UzDRYuCuXJyaup92/6h/Y4/3LtAEEO0ZmAZhU2F+ozb6N1bWYVPFbtFyJNNkK+qCJAdDgwJO3deTlYboQXlDefYFY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770232828; c=relaxed/simple; bh=EstM98oZkpRObgO+MlSheaium2mk6F+F2zNJu7IFwGo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=b5g3eLPW+Wp9ECjMRqWd0zkxjE70yU86/b2oIB1oqIaAgnqWNSuaCQ8CqnXPsd11J/eIV0f14XgS6+77Z9Xn04BkdduXfWccWJAa0hGnbjzwL8n5J9PesY2iLcxFTdIOcIL/Jlc29eHn7ZhdJJYE2eWPPm0GKP0a6oyMVDez6Wg= 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=F24YiZDs; arc=none smtp.client-ip=79.135.106.30 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="F24YiZDs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1770232820; x=1770492020; bh=ptw23Z9OmNt62k8RVBE3UdzBsOYblPWBb2QZBa+XI8M=; 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=F24YiZDsMuRdMU4BsHh0QaYfqre5TCZmoJS7eE0uiR/sFwbmCVgWr0c22lC4Co1AD ttzTEnbra5HOPpsns7lZB6pRvy8qUfaCT9ogKLGcMv0a0XgGwGj2bEU1/ye+//h/i7 ekKpQzVXLLEP+QJiR8hjxj4eS6HZ+LAa/fuAz2sJsOFihm2o9dlAKb7TrfnGXNDiim mBWdQYXRnC6J+2iAjfFyefqAVZD/D9ka/6b95xmbuP8rTKquglhSeap1UJuUQhwyQ4 5U7KpIoIvyGpcve3Do8Mt2BEOEKJRaa6YaHFtpyfxRasIggAw/muLWyk0XsoD0E878 79DXKXcj/PHNg== Date: Wed, 04 Feb 2026 19:20:15 +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 v10 09/13] x86/mm: Reset tags in a canonical address helper call Message-ID: <8c1d34e7d8d9fdeb836230160c9207e7bc06e0ee.1770232424.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 5c3d55b4bbfb9fdc153dbdac3fbc2f7b1a5f59bc 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.53.0