Re: [PATCH bpf 1/3] bpf: Explicitly check accesses to bpf_sock_addr

[Paul Chaignon <paul.chaignon@gmail.com>]

On Tue, Sep 16, 2025 at 03:45:51PM -0700, Eduard Zingerman wrote:
> On Tue, 2025-09-16 at 17:17 +0200, Paul Chaignon wrote:
> > Syzkaller found a kernel warning on the following sock_addr program:
> > 
> >     0: r0 = 0
> >     1: r2 = *(u32 *)(r1 +60)
> >     2: exit
> > 
> > which triggers:
> > 
> >     verifier bug: error during ctx access conversion (0)
> > 
> > This is happening because offset 60 in bpf_sock_addr corresponds to an
> > implicit padding of 4 bytes, right after msg_src_ip4. Access to this
> > padding isn't rejected in sock_addr_is_valid_access and it thus later
> > fails to convert the access.
> > 
> > This patch fixes it by explicitly checking the various fields of
> > bpf_sock_addr in sock_addr_is_valid_access.
> > 
> > I checked the other ctx structures and is_valid_access functions and
> > didn't find any other similar cases. Other cases of (properly handled)
> > padding are covered in new tests in a subsequent patch.
> > 
> > Fixes: 1cedee13d25a ("bpf: Hooks for sys_sendmsg")
> > Reported-by: syzbot+136ca59d411f92e821b7@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=136ca59d411f92e821b7
> > Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
> > ---
> 
> Double checked other context types with holes and paddings:
> - bpf_sk_lookup
> - bpf_sock
> - __sk_buff
> - sk_reuseport_md
> 
> And agree with Paul's conclusion.
> (Note, however, that bpf_sock and __sk_buff explicitly refer to
>  padding offsets).

Thanks for double checking! I think I had missed sk_reuseport_md when
going through those. I had also forgotten the test case for bpf_sock.
I added both as selftests in the v2.

> 
> Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> 
> [...]