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

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.

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.

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.