[RFC PATCH 0/2] x86/vsyscall: Tighten vsyscall emulation checks for a #PF fixup

[RFC PATCH 0/2] x86/vsyscall: Tighten vsyscall emulation checks for a #PF fixup

[Sohil Mehta]

This series is a result of the suggestions made by Peter Anvin at
https://lore.kernel.org/lkml/2074c00d-2e73-4bd9-89d2-7b0a015b134e@zytor.com/.

The vsyscall emulation code already has a bunch of checks to make sure
only valid page faults get emulated. This series improves those checks
mainly from the defensive point of view.

The patches are based on the LASS-vsyscall series under review at
https://lore.kernel.org/lkml/20260309181029.398498-1-sohil.mehta@intel.com/

Patch 1 seems like a straightforward change that is unlikely to cause
any issues.

Patch 2 adds a few more PF error codes to the emulation reject-list.
But, it is debatable whether they are absolutely necessary.

  X86_PF_RSVD: Reserved bits being set in do_user_addr_fault() already
  generates an OOPS before vsyscall emulation attempted. No need to
  check for it again.

  X86_PF_PK: PKRU never rejects instruction fetches so it is highly
  unlikely the vsyscall emulation code will be reached with this bit
  set.

  X86_PF_SHSTK: I am not sure if we can have a vsyscall page access that
  results in X86_PF_SHSTK set but doesn't have X86_PF_WRITE with it. If
  we cannot, the current checks in emulate_vsyscall_pf() will already
  reject emulation.

I have included X86_PF_PK and X86_PF_SHSTK in patch 2 because I am not a
100% sure about the reasoning. Additionally, I don't see any harm in
including them. Also, should we also add X86_PF_SGX and X86_PF_RMP by
the same logic? Any insight here would be appreciated.

The patches pass the vsyscall selftest. But, they should be considered
untested as I don't know how to generate these PF error codes in the
vsyscall context.

Sohil Mehta (2):
  x86/vsyscall: Avoid vsyscall emulation when X86_PF_INSTR is not set
  x86/vsyscall: Avoid vsyscall emulation for some unexpected fault types

 arch/x86/entry/vsyscall/vsyscall_64.c | 10 ++++++----
 arch/x86/mm/fault.c                   |  3 ---
 2 files changed, 6 insertions(+), 7 deletions(-)

-- 
2.43.0

[RFC PATCH 1/2] x86/vsyscall: Avoid vsyscall emulation when X86_PF_INSTR is not set

[Sohil Mehta]

On systems that support X86_FEATURE_NX, X86_PF_INSTR is expected to be
set in the PFEC when a #PF is triggered due to an instruction fetch on a
vsyscall page.

Commit 8ba38a7a9a69 ("x86/vsyscall: Do not require X86_PF_INSTR to
emulate vsyscall") changed the requirement for X86_PF_INSTR to be set
because X86_FEATURE_NX may not be available on some platforms. Vsyscall
emulation now relies on the fact that, in the case of a #PF due to an
instruction fetch, the RIP will always match the vsyscall fault address
reported via CR2.

The kernel still issues a warning if X86_PF_INSTR is not set when
X86_FEATURE_NX is enabled. However, this warning is almost impossible to
trigger unless something is very wrong. Instead of continuing, avoid
vsyscall emulation in this extremely unlikely situation.

Suggested-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
 arch/x86/entry/vsyscall/vsyscall_64.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index ea36de9fa864..b1f8f8a57b02 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -282,8 +282,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);
 }
-- 
2.43.0

[RFC PATCH 2/2] x86/vsyscall: Avoid vsyscall emulation for some unexpected fault types

[Sohil Mehta]

Currently, vsyscall emulation is rejected for write faults and
kernel-privilege faults. Other page fault error codes such as X86_PF_PK
and X86_PF_SHSTK are unlikely to be set in the vsyscall context.

However, it is good to explicitly reject them from a defensive point of
view. So, avoid vsyscall emulation if X86_PF_PK or X86_PF_SHSTK is set.

Note, X86_PF_RSVD is already handled in do_user_addr_fault() before
vsyscall emulation is attempted.

Suggested-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
 arch/x86/entry/vsyscall/vsyscall_64.c | 5 +++--
 arch/x86/mm/fault.c                   | 3 ---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index b1f8f8a57b02..bf0ae314a0fb 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, PK or shadow stack). */
+	if ((error_code & (X86_PF_WRITE | X86_PF_PK | X86_PF_SHSTK | X86_PF_USER)) !=
+	    X86_PF_USER)
 		return false;
 
 	/*
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index f0e77e084482..004b242ebbf8 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1309,9 +1309,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

Re: [RFC PATCH 0/2] x86/vsyscall: Tighten vsyscall emulation checks for a #PF fixup

[Edgecombe, Rick P]

On Fri, 2026-03-13 at 12:23 -0700, Sohil Mehta wrote:
>   X86_PF_SHSTK: I am not sure if we can have a vsyscall page access
> that results in X86_PF_SHSTK set but doesn't have X86_PF_WRITE with
> it. If we cannot, the current checks in emulate_vsyscall_pf() will
> already reject emulation.

There are shadow stack read accesses. This would be pretty hard to make
happen to the vsyscall page though. I think it might be impossible.
Ptrace should reject kernel addresses for the SSP. And I don't know how
else you could get the SSP pointed at it. There is WRSS instruction,
but that only generates writes.

It is probably fair to say userspace will not care about the case.

Re: [RFC PATCH 0/2] x86/vsyscall: Tighten vsyscall emulation checks for a #PF fixup

[Edgecombe, Rick P]

On Fri, 2026-03-13 at 12:23 -0700, Sohil Mehta wrote:
>   X86_PF_SHSTK: I am not sure if we can have a vsyscall page access
> that results in X86_PF_SHSTK set but doesn't have X86_PF_WRITE with
> it. If we cannot, the current checks in emulate_vsyscall_pf() will
> already reject emulation.

There are shadow stack read accesses. This would be pretty hard to make
happen to the vsyscall page though. I think it might be impossible.
Ptrace should reject kernel addresses for the SSP. And I don't know how
else you could get the SSP pointed at it. There is WRSS instruction,
but that only generates writes.

It is probably fair to say userspace will not care about the case.

Re: [RFC PATCH 0/2] x86/vsyscall: Tighten vsyscall emulation checks for a #PF fixup

[Sohil Mehta]

On 3/18/2026 11:47 AM, Edgecombe, Rick P wrote:
> On Fri, 2026-03-13 at 12:23 -0700, Sohil Mehta wrote:
>>   X86_PF_SHSTK: I am not sure if we can have a vsyscall page access
>> that results in X86_PF_SHSTK set but doesn't have X86_PF_WRITE with
>> it. If we cannot, the current checks in emulate_vsyscall_pf() will
>> already reject emulation.
> 
> There are shadow stack read accesses. This would be pretty hard to make
> happen to the vsyscall page though. I think it might be impossible.
> Ptrace should reject kernel addresses for the SSP. And I don't know how
> else you could get the SSP pointed at it. There is WRSS instruction,
> but that only generates writes.
> 
> It is probably fair to say userspace will not care about the case.
> 
> 

Thanks for the insight. As userspace wouldn't care, and the cost of
adding the X86_PF_SHSTK check is almost zero, I'll keep the X86_PF_SHSTK
in patch 2.

For the next version, I will combine patch 1 and 2 as they are
essentially doing similar things. I am still unsure about X86_PF_SGX and
X86_PF_RMP. Unless someone with knowledge chimes in, I'll leave them out
of the checks for now.