From: Oleg Nesterov <oleg@redhat.com>
To: Andrii Nakryiko <andrii@kernel.org>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Jiri Olsa <jolsa@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Paulo Andrade <pandrade@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [BUG] x86: 32-bit uprobes are broken
Date: Wed, 7 Jan 2026 15:32:53 +0100 [thread overview]
Message-ID: <aV5uldEvV7pb4RA8@redhat.com> (raw)
Paulo reported that uprobing the 32-bit tasks is broken.
This script
#!/usr/bin/bash
echo 0 > /proc/sys/kernel/randomize_va_space
echo 'void main(void) {}' > TEST.c
# -fcf-protection to ensure that the 1st endbr32 insn can't be eulated
gcc -m32 -fcf-protection=branch TEST.c -o test
bpftrace -e 'uprobe:./test:main {}' -c ./test
"hangs", the probed ./test task enters the endless loop.
This patch
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1710,8 +1710,11 @@ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area)
if (!area->vaddr) {
/* Try to map as high as possible, this is only a hint. */
+ if (test_thread_flag(TIF_ADDR32))
+ current_thread_info()->status |= TS_COMPAT;
area->vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE,
PAGE_SIZE, 0, 0);
+ current_thread_info()->status &= ~TS_COMPAT;
if (IS_ERR_VALUE(area->vaddr)) {
ret = area->vaddr;
goto fail;
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;
"fixes" the problem.
-----------------------------------------------------------------------------------------
The problem is that with randomize_va_space == 0 get_unmapped_area(TASK_SIZE - PAGE_SIZE)
called by xol_add_vma() can't just return the "addr == TASK_SIZE - PAGE_SIZE" hint, this
addr is used by the stack vma.
arch_get_unmapped_area/arch_get_unmapped_area_topdown() doesn't take TIF_ADDR32 into
account and in_32bit_syscall() is false, this leads to info.high_limit > TASK_SIZE.
get_area() happily returns the "high" address and then get_unmapped_area() returns
ENOMEM after the
if (addr > TASK_SIZE - len)
return -ENOMEM;
check; TASK_SIZE checks TIF_ADDR32.
handle_swbp() doesn't report this failure (probably it should) and silently restarts
the probed insn. Endless loop.
-----------------------------------------------------------------------------------------
I am considering the patch which adds something like
// x86 version will use the TS_COMPAT hack
unsigned long __weak arch_uprobe_area(void)
{
return get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE, 0, 0);
}
but perhaps there is a better solution? perhaps it makes more sense to change
arch/x86/kernel/sys_x86_64.c? What is the point of ignoring TIF_ADDR32 if the
high adress will be nacked by the "if (addr > TASK_SIZE - len)" check anyway?
Oleg.
next reply other threads:[~2026-01-07 14:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 14:32 Oleg Nesterov [this message]
2026-01-07 15:27 ` [BUG] x86: 32-bit uprobes are broken Peter Zijlstra
2026-01-07 15:52 ` Oleg Nesterov
2026-01-10 15:37 ` Oleg Nesterov
2026-01-11 15:00 ` [PATCH] x86/uprobes: Fix XOL allocation failure for 32-bit tasks Oleg Nesterov
2026-01-12 16:40 ` Peter Zijlstra
2026-01-12 17:40 ` Oleg Nesterov
2026-01-14 13:10 ` Oleg Nesterov
2026-01-15 21:43 ` [tip: perf/core] " tip-bot2 for Oleg Nesterov
2026-01-16 10:00 ` Oleg Nesterov
2026-01-16 10:41 ` Peter Zijlstra
2026-01-16 10:49 ` tip-bot2 for Oleg Nesterov
2026-01-16 15:27 ` tip-bot2 for Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aV5uldEvV7pb4RA8@redhat.com \
--to=oleg@redhat.com \
--cc=andrii@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hpa@zytor.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=pandrade@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox