mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sohil Mehta <sohil.mehta@intel.com>
To: Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, Andy Lutomirski <luto@kernel.org>,
	Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Sohil Mehta <sohil.mehta@intel.com>,
	Nam Cao <namcao@linutronix.de>,
	Cedric Xing <cedric.xing@intel.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michael Roth <michael.roth@amd.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2] x86/vsyscall: Avoid vsyscall emulation for unexpected page fault types
Date: Tue, 21 Jul 2026 17:41:51 -0700	[thread overview]
Message-ID: <20260722004152.503073-1-sohil.mehta@intel.com> (raw)

Currently, vsyscall emulation is rejected for write faults and
kernel-privilege faults. It is assumed that other page fault error codes
such as X86_PF_PK and X86_PF_SHSTK will not be set in the vsyscall
context. From a defensive point of view, it is better to explicitly
reject these faults than assume that they will never happen. So, avoid
vsyscall emulation if any of those are present.

Note, X86_PF_SGX and X86_PF_RMP are also unlikely to occur in the
vsyscall context. They can probably be added to the reject-list in the
future to solidify this further. Also, X86_PF_RSVD is already handled in
do_user_addr_fault() before vsyscall emulation is attempted.

Similarly, on systems that support X86_FEATURE_NX, X86_PF_INSTR is
always expected to be set when an instruction fetch triggers a #PF. The
kernel issues a warning whenever that is not the case. Instead of
continuing when something is very wrong, return early and skip vsyscall
emulation.

Suggested-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v2:
 - Combined the two patches into one.
 - Make the commit message concise.

I have excluded SGX and RMP because I wasn't 100% sure and I didn't get
any feedback on them in the last post. Let me know if someone wants them
to be added.
RFC-v1: https://lore.kernel.org/lkml/20260313192327.2089471-1-sohil.mehta@intel.com/
---
 arch/x86/entry/vsyscall/vsyscall_64.c | 10 ++++++----
 arch/x86/mm/fault.c                   |  3 ---
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index ea36de9fa864..5176860cef55 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -257,8 +257,9 @@ static bool __emulate_vsyscall(struct pt_regs *regs, unsigned long address)
 bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs,
 			 unsigned long address)
 {
-	/* Write faults or kernel-privilege faults never get fixed up. */
-	if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER)
+	/* Only simple user read faults get fixed up (no write, pkey or shadow stack) */
+	if ((error_code & (X86_PF_WRITE | X86_PF_PK | X86_PF_SHSTK | X86_PF_USER)) !=
+	    X86_PF_USER)
 		return false;
 
 	/*
@@ -282,8 +283,9 @@ bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs,
 	 * available, use it to double-check that the emulation code
 	 * is only being used for instruction fetches:
 	 */
-	if (cpu_feature_enabled(X86_FEATURE_NX))
-		WARN_ON_ONCE(!(error_code & X86_PF_INSTR));
+	if (cpu_feature_enabled(X86_FEATURE_NX) &&
+	    WARN_ON_ONCE(!(error_code & X86_PF_INSTR)))
+		return false;
 
 	return __emulate_vsyscall(regs, address);
 }
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 45b99c3b1442..e0b645a55844 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1318,9 +1318,6 @@ void do_user_addr_fault(struct pt_regs *regs,
 	 *
 	 * The vsyscall page does not have a "real" VMA, so do this
 	 * emulation before we go searching for VMAs.
-	 *
-	 * PKRU never rejects instruction fetches, so we don't need
-	 * to consider the PF_PK bit.
 	 */
 	if (is_vsyscall_vaddr(address)) {
 		if (emulate_vsyscall_pf(error_code, regs, address))
-- 
2.43.0


             reply	other threads:[~2026-07-22  0:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22  0:41 Sohil Mehta [this message]
2026-07-22 15:36 ` Jarkko Sakkinen

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=20260722004152.503073-1-sohil.mehta@intel.com \
    --to=sohil.mehta@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=cedric.xing@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=memxor@gmail.com \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=namcao@linutronix.de \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --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®