From: Chris Down <chris@chrisdown.name>
To: Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
x86@kernel.org
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>, Jeff Moyer <jmoyer@redhat.com>,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
stable@vger.kernel.org
Subject: [PATCH] x86/mm/pat: Don't leak reservations at the physical address limit
Date: Sat, 7 Nov 2026 21:25:57 -0800 [thread overview]
Message-ID: <avAH5XMCbIWvdD8R@chrisdown.name> (raw)
memtype_reserve() and memtype_free() pass their physical addresses
through sanitize_phys(). Both take an exclusive end address, but
sanitize_phys() expects an inclusive one.
So this has the effect that for a range that ends exactly at the top of
the physical address space, the mask turns the end into 0.
As a result the ISA range check succeeds and memtype_free() returns 0
without removing the reservation. A new reservation that overlaps
existing entries takes on their memory type, so the stale entry goes on
choosing the cache mode for that range.
Let's fix this by doing some annoying off by one twiddling.
Fixes: aeef8b5089b7 ("x86/pat: Pass valid address to sanitize_phys()")
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Down <chris@chrisdown.name>
---
arch/x86/mm/pat/memtype.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index cf94fb561310..007d833b4c00 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -613,7 +613,7 @@ int memtype_free(u64 start, u64 end)
return 0;
start = sanitize_phys(start);
- end = sanitize_phys(end);
+ end = sanitize_phys(end - 1) + 1;
/* Low ISA region is always mapped WB. No need to track */
if (x86_platform.is_untracked_pat_range(start, end))
base-commit: 5cdc3746fa163fb4e8d05fa3cabf46bc6aa7df75
reply other threads:[~2026-11-08 5:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avAH5XMCbIWvdD8R@chrisdown.name \
--to=chris@chrisdown.name \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jmoyer@redhat.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®