]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
x86/entry/vdso32: Don't rely on int80_landing_pad for adjusting ip
authorH. Peter Anvin <hpa@zytor.com>
Tue, 16 Dec 2025 21:25:58 +0000 (13:25 -0800)
committerDave Hansen <dave.hansen@linux.intel.com>
Wed, 14 Jan 2026 00:37:58 +0000 (16:37 -0800)
commit6e150b71019f386a021004fafea9ef7189bc6aea
treedbb2e720254845e81d03cafb408c9fdf33f25912
parent693c819fedcdcabfda7488e2d5e355a84c2fd1b0
x86/entry/vdso32: Don't rely on int80_landing_pad for adjusting ip

There is no fundamental reason to use the int80_landing_pad symbol to
adjust ip when moving the vdso. If ip falls within the vdso, and the
vdso is moved, we should change the ip accordingly, regardless of mode
or location within the vdso. This *currently* can only happen on 32
bits, but there isn't any reason not to do so generically.

Note that if this is ever possible from a vdso-internal call, then the
user space stack will also needed to be adjusted (as well as the
shadow stack, if enabled.) Fortunately this is not currently the case.

At the moment, we don't even consider other threads when moving the
vdso. The assumption is that it is only used by process freeze/thaw
for migration, where this is not an issue.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://patch.msgid.link/20251216212606.1325678-5-hpa@zytor.com
arch/x86/entry/vdso/vma.c