Re: [PATCH bpf-next v1 1/3] x86/mm: Resolve BPF exception fixups for user address faults under SMAP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: PROBE_MEM oops during RCU grace period due to early kallsyms removal
--

commit 9e4e375ce4c3205ad3741d292c6701b8a1d5a5c3
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

x86/mm: Resolve BPF exception fixups for user address faults under SMAP

This commit allows the x86 page fault handler to resolve BPF PROBE_MEM
exception table entries for user address faults when SMAP is enabled, avoiding
an immediate oops. It paves the way for dropping the JIT-emitted address
range checks.

> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index aa88370ce7394..2060e5f35d77a 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c

[ ... ]

> @@ -1262,6 +1263,16 @@ void do_user_addr_fault(struct pt_regs *regs,
>  	if (unlikely(cpu_feature_enabled(X86_FEATURE_SMAP) &&
>  		     !(error_code & X86_PF_USER) &&
>  		     !(regs->flags & X86_EFLAGS_AC))) {
> +		/*
> +		 * JITed BPF programs dereference untrusted pointers with loads
> +		 * that carry an exception table entry (PROBE_MEM). SMAP makes
> +		 * sure such a load cannot read user memory, so resolve the
> +		 * fault through the exception table, as for an unmapped kernel
> +		 * address, instead of oopsing.
> +		 */
> +		if (is_bpf_text_address(regs->ip) &&
> +		    fixup_exception(regs, X86_TRAP_PF, error_code, address))
> +			return;

[Severity: High]
Does this introduce a race condition during BPF program destruction?

If a BPF program with PROBE_MEM loads has its reference count drop to zero,
__bpf_prog_put_noref() synchronously removes it from the global bpf_tree via
bpf_prog_kallsyms_del_all() before waiting for the RCU grace period:

kernel/bpf/syscall.c:__bpf_prog_put_noref() {
    ...
    bpf_prog_kallsyms_del_all(prog);
    ...
    if (deferred) {
        ...
        call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
    ...
}

If a CPU is still executing this program inside an RCU read-side critical
section and hits a PROBE_MEM fault, could the page fault handler fail to find
the actively executing program?

The handler calls is_bpf_text_address() and then fixup_exception(), which
eventually searches for the program using bpf_prog_ksym_find():

kernel/bpf/core.c:search_bpf_extables() {
    rcu_read_lock();
    prog = bpf_prog_ksym_find(addr);
    if (!prog)
        goto out;
    ...
}

Because the program was already cleared from bpf_tree, is_bpf_text_address()
and fixup_exception() will fail to resolve the exception, causing the kernel to
incorrectly fall through to page_fault_oops() instead.

>  		/*
>  		 * No extable entry here.  This was a kernel access to an
>  		 * invalid pointer.  get_kernel_nofault() will not get here.
>  		 */
>  		page_fault_oops(regs, error_code, address);
>  		return;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009024925.3169077-1-memxor@gmail.com?part=1