From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: "Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
"Syeda Mahnur Asif" <s.mahnur.a@gmail.com>
Cc: <bpf@vger.kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>,
<netdev@vger.kernel.org>, <andrii@kernel.org>,
"Emil Tsalapatis" <emil@etsalapatis.com>
Subject: Re: [PATCH bpf v2] bpf: Fix NULL pointer dereference in bpf_sock_from_file
Date: Fri, 21 Aug 2026 19:36:46 +0200 [thread overview]
Message-ID: <DKUSYFLEQ39S.2QP1DOZV5PZOP@gmail.com> (raw)
In-Reply-To: <CAEf4BzZd7BDdJrNb+N3uktbwMJRHjUFzG1xfzmTDibEmAKX8gA@mail.gmail.com>
On Fri Aug 21, 2026 at 7:30 PM CEST, Andrii Nakryiko wrote:
> On Thu, Aug 20, 2026 at 8:25 AM Syeda Mahnur Asif <s.mahnur.a@gmail.com> wrote:
>>
>> 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")
>> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
>> Signed-off-by: Syeda Mahnur Asif <s.mahnur.a@gmail.com>
>> ---
>> v2:
>> - Added Reviewed-by from Emil Tsalapatis
>> - Fixed name in Signed-off-by
>>
>> net/core/filter.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/core/filter.c b/net/core/filter.c
>> index 16845987b244..7c3caae4bafc 100644
>> --- a/net/core/filter.c
>> +++ b/net/core/filter.c
>> @@ -12182,7 +12182,10 @@ const struct bpf_func_proto bpf_skc_to_mptcp_sock_proto = {
>>
>> BPF_CALL_1(bpf_sock_from_file, struct file *, file)
>> {
>> - return (unsigned long)sock_from_file(file);
>> + if (file)
>> + return (unsigned long)sock_from_file(file);
>
> given this is a legacy ARG_PTR_TO_BTF_ID, it can be not just NULL, but
> also a) small value bogus "pointer" resulting from NULL + offset
> calculation and/or b) just random garbage casted to struct file
> pointer with bpf_core_cast() (maybe this hole we've closed with
> explicitly untrusted, not sure).
>
> Either way, this is not a sufficient fix at least.
>
> But I wonder if the proper fix is actually to mark this (and other
> similar) argument as explicitly requiring trusted PTR_TO_BTF_ID?
>
> Thoughts?
>
+1, should bite the bullet and accelerate deprecation of legacy PTR_TO_BTF_ID.
We can mark specific arguments / fields in structs as trusted where there is a
legitimate use case and the kernel guarantees their lifetime appropriately.
>> +
>> + return (unsigned long)NULL;
>> }
>>
>> BTF_ID_LIST(bpf_sock_from_file_btf_ids)
>> --
>> 2.53.0
>>
prev parent reply other threads:[~2026-08-21 17:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 15:25 [PATCH bpf v2] bpf: Fix NULL pointer dereference in bpf_sock_from_file Syeda Mahnur Asif
2026-08-20 15:44 ` sashiko-bot
2026-08-21 17:30 ` Andrii Nakryiko
2026-08-21 17:36 ` Kumar Kartikeya Dwivedi [this message]
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=DKUSYFLEQ39S.2QP1DOZV5PZOP@gmail.com \
--to=memxor@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=emil@etsalapatis.com \
--cc=netdev@vger.kernel.org \
--cc=s.mahnur.a@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.