linux-kernel - [tip: x86/entry] x86/entry/vdso32: Don't rely on int80_landing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <176835149579.510.18025799979884459481.tip-bot2@tip-bot2>
Date: Wed, 14 Jan 2026 00:44:55 -0000
From: "tip-bot2 for H. Peter Anvin" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: "H. Peter Anvin (Intel)" <hpa@...or.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Subject: [tip: x86/entry] x86/entry/vdso32: Don't rely on int80_landing_pad
 for adjusting ip

The following commit has been merged into the x86/entry branch of tip:

Commit-ID:     6e150b71019f386a021004fafea9ef7189bc6aea
Gitweb:        https://git.kernel.org/tip/6e150b71019f386a021004fafea9ef7189bc6aea
Author:        H. Peter Anvin <hpa@...or.com>
AuthorDate:    Tue, 16 Dec 2025 13:25:58 -08:00
Committer:     Dave Hansen <dave.hansen@...ux.intel.com>
CommitterDate: Tue, 13 Jan 2026 16:37:58 -08:00

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@...or.com>
Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Link: https://patch.msgid.link/20251216212606.1325678-5-hpa@zytor.com
---
 arch/x86/entry/vdso/vma.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 8f98c2d..e7fd751 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -65,16 +65,12 @@ static vm_fault_t vdso_fault(const struct vm_special_mapping *sm,
 static void vdso_fix_landing(const struct vdso_image *image,
 		struct vm_area_struct *new_vma)
 {
-	if (in_ia32_syscall() && image == &vdso32_image) {
-		struct pt_regs *regs = current_pt_regs();
-		unsigned long vdso_land = image->sym_int80_landing_pad;
-		unsigned long old_land_addr = vdso_land +
-			(unsigned long)current->mm->context.vdso;
-
-		/* Fixing userspace landing - look at do_fast_syscall_32 */
-		if (regs->ip == old_land_addr)
-			regs->ip = new_vma->vm_start + vdso_land;
-	}
+	struct pt_regs *regs = current_pt_regs();
+	unsigned long ipoffset = regs->ip -
+		(unsigned long)current->mm->context.vdso;
+
+	if (ipoffset < image->size)
+		regs->ip = new_vma->vm_start + ipoffset;
 }

 static int vdso_mremap(const struct vm_special_mapping *sm,