Re: [PATCHv3 bpf-next 2/8] bpf: Add user memory kfuncs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: bpf_user_anon_mmap() triggers false in_32bit_syscall() on x86_64
--

commit db9c75bc63d6f183a3894259aadc59e0c0a612de
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Add user memory kfuncs

This commit adds the sleepable bpf_copy_to_user(), bpf_user_anon_mmap(),
and bpf_user_munmap() kfuncs for BPF_PROG_TYPE_KPROBE programs to manipulate
the current process's user address space.

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index 6788489a2608b..937a0d7d68390 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c

[ ... ]

> @@ -3768,6 +3771,88 @@ __bpf_kfunc int bpf_copy_from_user_mm(void *dst, u32 dst__sz,

[ ... ]

> +__bpf_kfunc unsigned long bpf_user_anon_mmap(unsigned long len, unsigned long prot)
> +{
> +	if (!bpf_user_mm_ok())
> +		return -EPERM;
> +	if (!arch_validate_prot(prot, 0))
> +		return -EINVAL;
> +	return vm_mmap(NULL, 0, len, prot, MAP_PRIVATE | MAP_ANONYMOUS, 0);
> +}

[Severity: Medium]
As reported by bot+bpf-ci@kernel.org on v1 [1], when bpf_user_anon_mmap() is
called from a sleepable uprobe or uretprobe on x86_64 with
CONFIG_X86_X32_ABI=y, can this falsely trigger in_32bit_syscall() for native
64-bit processes and restrict the mapping to the 32-bit compatibility address
range?

On x86_64, entering a uprobe or uretprobe via an int3 trap or via
sys_uprobe / sys_uretprobe sets task_pt_regs(current)->orig_ax to -1. Under
CONFIG_X86_X32_ABI=y, in_32bit_syscall() checks in_x32_syscall():

arch/x86/include/asm/compat.h:
static inline bool in_x32_syscall(void)
{
#ifdef CONFIG_X86_X32_ABI
	if (task_pt_regs(current)->orig_ax & __X32_SYSCALL_BIT)
		return true;
#endif
	return false;
}

Because bpf_user_anon_mmap() passes addr = 0 to vm_mmap(),
__get_unmapped_area() calls arch_get_unmapped_area_topdown() /
arch_get_unmapped_area(), which invoke get_mmap_base() and find_start_end():

arch/x86/mm/mmap.c:get_mmap_base() {
    ...
#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
	if (in_32bit_syscall()) {
		return is_legacy ? mm->mmap_compat_legacy_base
				 : mm->mmap_compat_base;
	}
#endif
    ...
}

Since orig_ax is -1, in_32bit_syscall() (and in_compat_syscall() in
__thp_get_unmapped_area()) evaluates to true, placing mappings for native
64-bit tasks below 4 GiB and failing with -ENOMEM if the low 4 GiB range is
exhausted or len exceeds task_size_32bit().

[1] https://lore.kernel.org/r/571f32a410a85199bc9bcecfe07a9a9b6ef425b2052643e64031dd246c13691e@mail.kernel.org

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105102343.311331-1-jolsa@kernel.org?part=1