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

[Oleg Nesterov <oleg@redhat.com>]

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.