On Thu, May 23, 2024 at 09:19:01PM GMT, Shung-Hsi Yu wrote:
> Looking at commit ecc6a2101840 ("bpf: Protect against int overflow for
> stack access size") and the associated syzbot report (linked below), it
> seems that the underlying issue is that access_size argument
> check_helper_mem_access() can be overflowed.
>
> E.g. with a bloom filter where the value size is INT_MAX+2
>
> 4: type 30 flags 0x0
> key 0B value 2147483649B max_entries 255 memlock 720B
>
> The ARG_PTR_TO_MAP_VALUE case in check_func_arg() could overflow
> access_size. (Potentially in the ARG_PTR_TO_MAP_KEY case as well)
>
> case ARG_PTR_TO_MAP_VALUE:
> /* value_size is u32, access_size is int */
> err = check_helper_mem_access(env, regno,
> meta->map_ptr->value_size, false,
> meta);
>
> Should we guard against such overflow?
Oops, just realize that previous patch in the series, commit
a8d89feba7e5 ("bpf: Check bloom filter map value size"), already address
the issue by limiting value_size to KMALLOC_MAX_SIZE and mentioned that
what done for value_size for other map types as well.
Sorry for the noise.
> ...
