[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <99bfc3be-0517-4e17-b7a5-e504b751d8bf@linux.dev>
Date: Wed, 4 Feb 2026 12:18:12 -0800
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Kuniyuki Iwashima <kuniyu@...gle.com>, Michal Luczaj <mhal@...x.co>
Cc: bpf@...r.kernel.org, daniel@...earbox.net, davem@...emloft.net,
edumazet@...gle.com, horms@...nel.org, jakub@...udflare.com,
john.fastabend@...il.com, kuba@...nel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH bpf] bpf, sockmap: Fix af_unix null-ptr-deref in proto
update
On 2/4/26 11:16 AM, Kuniyuki Iwashima wrote:
> For example, inet_sock(sk)->inet_opt could be freed by
> setsockopt(IP_OPTIONS) even after fentry prog verifies
> that it's not NULL.
This one should be fine because of rcu.
>
> I'm not sure if bpf_core_cast() etc allows such access, but
> if it's allowed, I think there is no general solution.
bpf_core_cast (i.e. the "kfunc" bpf_rdonly_cast) does not use the
pointer argument, so should be fine. Its return value is marked as
PTR_UNTRUSTED. iirc, PTR_UNTRUSTED cannot be passed to helper, so
bpf_core_cast should be fine overall.
>
> Fortunately that's not null-deref nor oob-write, and it just reads
> stale info as Martin mentioned... so probably this is WAI for
> tracing prog ?
afaik, the tracing radius is large, so the prog cannot expect much
guarantee.
Reading in the bpf prog is fine. The exception is handled.
The problem here is passing it to a helper (not kfunc) that depends on
the arg being valid.
Powered by blists - more mailing lists