[PATCH] x86/entry/32: Harden return-to-user

[PATCH] x86/entry/32: Harden return-to-user

[Andrey Zakharov]

Commit 1e4d3001f59f ("x86/entry: Harden return-to-user") made the
check that the IRET frame returns to user mode unconditional on
x86-64. The 32-bit entry code has no equivalent: restore_all_switch_stack
executes IRET with whatever CS is in the frame. The exception return
path tests CS to choose between returning to the kernel and to user
mode, but the system call return paths (int $0x80, the SYSENTER
fallback and ret_from_fork) do not test it before reaching
restore_all_switch_stack.

Add an unconditional check to restore_all_switch_stack, after the
registers are restored. It requires that CS in the IRET frame has a
user RPL, or that EFLAGS.VM is set for vm86, and traps with UD2
otherwise. It is placed before CLEAR_CPU_BUFFERS so that the buffer
clearing stays directly in front of the IRET. The exception return
path to the kernel jumps straight to .Lirq_return and does not go
through the new check.

Testing: built i386_defconfig plus CONFIG_X86_LEGACY_VM86=y with
gcc 16.2.1; the build reported no warnings. Booted it under
QEMU (TCG, -cpu max) with a minimal initramfs running the
entry_from_vm86, sigreturn, single_step_syscall and syscall_nt
selftests. The results match the unpatched kernel, ignoring the FLAGS
values printed by entry_from_vm86, which also differ between two runs
of the unpatched kernel. entry_from_vm86 reports a UMIP failure on both
kernels. As negative controls, making the RPL test always fail kills
init with UD2 at the first return to user space, and removing the
EFLAGS.VM exception makes entry_from_vm86 hit the UD2.

Not tested: real hardware, performance, the NMI and double fault exits,
builds with PTI enabled, and builds with CONFIG_X86_LEGACY_VM86
disabled.

Link: https://github.com/KSPP/linux/issues/41
Signed-off-by: Andrey Zakharov <dedemorow@gmail.com>
---
 arch/x86/entry/entry_32.S | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 92c0b4a94e0a..69f754e5657c 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -952,6 +952,14 @@ restore_all_switch_stack:
 
 	/* Restore user state */
 	RESTORE_REGS pop=4			# skip orig_eax/error_code
+
+	/* Assert that the IRET frame returns to user mode or vm86. */
+	testb	$USER_SEGMENT_RPL_MASK, 4(%esp)
+	jnz	.Lreturn_to_user_ok
+	testl	$X86_EFLAGS_VM, 8(%esp)
+	jnz	.Lreturn_to_user_ok
+	ud2
+.Lreturn_to_user_ok:
 	CLEAR_CPU_BUFFERS
 .Lirq_return:
 	/*
-- 
2.56.0

Re: [PATCH] x86/entry/32: Harden return-to-user

[Dave Hansen]

On 10/27/26 14:52, Andrey Zakharov wrote:
> --- a/arch/x86/entry/entry_32.S
> +++ b/arch/x86/entry/entry_32.S
> @@ -952,6 +952,14 @@ restore_all_switch_stack:
>  
>  	/* Restore user state */
>  	RESTORE_REGS pop=4			# skip orig_eax/error_code
> +
> +	/* Assert that the IRET frame returns to user mode or vm86. */
> +	testb	$USER_SEGMENT_RPL_MASK, 4(%esp)
> +	jnz	.Lreturn_to_user_ok
> +	testl	$X86_EFLAGS_VM, 8(%esp)
> +	jnz	.Lreturn_to_user_ok
> +	ud2
> +.Lreturn_to_user_ok:

I'm curious who cares.

Is anyone who is actually still running a 32-bit kernel concerned about
this kind of hardening?

If no one cares, then I'd rather pass on the complexity, even four
instructions of it.

Re: [PATCH] x86/entry/32: Harden return-to-user

[s1nkhole]

From: Andrey Zakharov <dedemorow@gmail.com>

On 10/27/26 15:01, Dave Hansen wrote:
> I'm curious who cares.
>
> Is anyone who is actually still running a 32-bit kernel concerned about
> this kind of hardening?
>
> If no one cares, then I'd rather pass on the complexity, even four
> instructions of it.

I don't know of anyone. The only motivation was KSPP issue #41, which
asks for parity with the x86-64 check added by 1e4d3001f59f, and that
issue is marked as low priority because 32-bit is legacy. I have no
report from a 32-bit user asking for it.

Please drop the patch. Thanks for looking at it.

If you have a moment: this is my first work on arch/x86, and I would like
to contribute something that is actually useful. Is there a small task
in x86/entry or in kernel hardening that you would suggest as a better
starting point, or a place where help with testing or review would be
welcome? I can build and run kernels under QEMU.

Thanks,
Andrey Zakharov

Re: [PATCH] x86/entry/32: Harden return-to-user

[Borislav Petkov]

On Wed, Oct 28, 2026 at 10:21:39PM +0300, s1nkhole wrote:
> If you have a moment: this is my first work on arch/x86, and I would like
> to contribute something that is actually useful. Is there a small task
> in x86/entry or in kernel hardening that you would suggest as a better
> starting point, or a place where help with testing or review would be
> welcome? I can build and run kernels under QEMU.

Review and testing is always welcome. As you can see, we're drowning in
patches. What we're not drowning in is reviewers who poke at submitted patches
critically and ask nasty questions.

And nowadays, reviewers even have help from Sashiko's LLM so doing that should
be even easier.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/entry/32: Harden return-to-user

[Dave Hansen]

On 10/28/26 12:21, s1nkhole wrote:
> If you have a moment: this is my first work on arch/x86, and I would like
> to contribute something that is actually useful. Is there a small task
> in x86/entry or in kernel hardening that you would suggest as a better
> starting point, or a place where help with testing or review would be
> welcome? I can build and run kernels under QEMU.

It's not small, but kernel shadow stacks are an _incredibly_ powerful
hardening tool. You can buy a system off the shelf that sanely supports
them (including FRED), but the kernel doesn't support them yet.

My current work in progress is here:

> https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=kss-2026-10-23

Another set of eyes on that would be nice. Although I do think I'm going
to abandon tacking the shadow stack on to the thread_union for now. So I
don't suggest looking at it too deeply until I get another version out
the door.

One thing you could do today is go into the list in here:

> https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/commit/?h=kss-2026-10-21&id=4dab5fe58904ee07b3622f25bbe3c1b7ff820bf5

and pick a feature or two and figure out if they need fixing for shadow
stacks or not, and if so what a fix might look like.

Or another set of eyes on this:

> https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=taskfun-2026-10-26

It's ready to post but I'm just waiting for the merge window to close.