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

[Eduard Zingerman <eddyz87@gmail.com>]

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).

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

[...]