Re: [PATCH bpf] bpf: Fix NULL pointer dereference in bpf_sock_from_file

> commit b394c2b75945f69ef4a6312d0fa18f1cc000d0c2
> Author: MahnurA <[email protected]>
> Date:   Tue Aug 18 19:42:53 2026 +0200
>
>     bpf: Fix NULL pointer dereference in bpf_sock_from_file
>
>     bpf_sock_from_file should not dereference a NULL file pointer.
>     KASAN detects a null-ptr-deref when eBPF tracing
>     fentry/fexit programs are attached to points such as
>     __mmap_region and file_map_prot_check kernel functions. This can
>     result in a NULL file pointer flowing from context to the helper.
>
>     A minimal check before dereferencing can fix this.
>
>     Fixes: b60da4955f53 ("bpf: Only provide bpf_sock_from_file with CONFIG_NET")
>     Signed-off-by: MahnurA <[email protected]>

Does the Fixes: tag reference the right commit?

Looking at b60da4955f53 ("bpf: Only provide bpf_sock_from_file with
CONFIG_NET"), that commit was a pure relocation: it deleted the helper from
kernel/trace/bpf_trace.c and re-added the identical body in net/core/filter.c,
and moved the proto dispatch from bpf_tracing_func_proto() to
tracing_prog_func_proto().

The body it moved was already:

    BPF_CALL_1(bpf_sock_from_file, struct file *, file)
    {
            return (unsigned long) sock_from_file(file);
    }

The unchecked dereference was introduced when the helper was first added, in
4f19cab76136 ("bpf: Add a bpf_sock_from_file helper"), which created exactly
that body. sock_from_file() in net/socket.c dereferences its argument
unconditionally via 'if (likely(file->f_op == &socket_file_ops))', so the
null-ptr-deref has existed since 4f19cab76136, not since b60da4955f53.

Should the Fixes: tag be:

  Fixes: 4f19cab76136 ("bpf: Add a bpf_sock_from_file helper")

Practical backport impact is small because both commits landed in the v5.11
merge window, but the tag is what stable/AUTOSEL tooling uses to pick a range,
and it points at a commit that did not introduce the bug.


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/32172667075