linux-kernel - Re: [BUG] x86: 32-bit uprobes are broken

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: <aWJyNm7_n8jUz8un@redhat.com>
Date: Sat, 10 Jan 2026 16:37:26 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Andrii Nakryiko <andrii@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	David Hildenbrand <david@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Jiri Olsa <jolsa@...nel.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Paulo Andrade <pandrade@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	x86@...nel.org
Subject: Re: [BUG] x86: 32-bit uprobes are broken

On 01/07, Peter Zijlstra wrote:
>
> On Wed, Jan 07, 2026 at 03:32:53PM +0100, Oleg Nesterov wrote:
>
> > or this one
> >
> > 	--- a/arch/x86/kernel/sys_x86_64.c
> > 	+++ b/arch/x86/kernel/sys_x86_64.c
> > 	@@ -205,6 +205,8 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr0,
> > 			info.low_limit = PAGE_SIZE;
> >
> > 		info.high_limit = get_mmap_base(0);
> > 	+	if (test_thread_flag(TIF_ADDR32))
> > 	+		info.high_limit = current->mm->mmap_compat_base;
> > 		if (!(filp && is_file_hugepages(filp))) {
> > 			info.start_gap = stack_guard_placement(vm_flags);
> > 			info.align_offset = pgoff << PAGE_SHIFT;
>
> This one would be broken if there is ever a case where
> get_unmapped_area() is called for mm != current->mm.
>
> Ah, but get_mmap_base() seems to already rely on that. What a mess :/

Yes, mm_get_unmapped_area_vmflags() paths assume mm == current->mm

> Why can't get_mmap_base() rely on TIF_ADDR32 rather than TS_COMPAT? What
> funny games are being played here? Mixed mode mm where some threads are
> 32bit and others are not?

Exactly. I don't understand this. And again, __get_unmapped_area() will use
TIF_ADDR32 in the "if (addr > TASK_SIZE - len)" check and return ENOMEM
anyway. I don't see the point in using in_32bit_syscall().

And. I just noticed another problem. What if CONFIG_X86_X32_ABI=y ?
In this case ->orig_ax = -1 and this makes in_x32_syscall() and thus
in_32bit_syscall() true.

OK, we need a simple fix for stable, I'll make a patch based on TS_COMPAT
hack for now.

Oleg.