Re: [PATCH bpf v3 2/5] bpf: Fix NULL-ptr-deref when showing a void BTF type

[Jiayuan Chen <jiayuan.chen@linux.dev>]

在 8/31/26 7:48 PM, bot+bpf-ci@kernel.org 写道:
>> bpf: Fix NULL-ptr-deref when showing a void BTF type
>>
>> btf_modifier_show() resolves the modifier and then calls
>> btf_type_ops(t)->show() unconditionally. For the void type (type_id 0,
>> BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL.
>>
>> The map dump path cannot reach a void type (a map key/value must have a
>> size and void has none), but bpf_snprintf_btf() takes a type_id straight
>> from the BPF program, and a "const void" (a modifier that resolves to
>> void, present in the vmlinux BTF) NULL-derefs there:
> Is this statement about the map dump path accurate? Looking at
> map_check_btf() in kernel/bpf/syscall.c, a map key isn't required to
> have a size:
>
> 	/* Some maps allow key to be unspecified. */
> 	if (btf_key_id) {
> 		key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
> 		if (!key_type || key_size != map->key_size)
> 			return -EINVAL;
> 	} else {
> 		key_type = btf_type_by_id(btf, 0);
> 		if (!map->ops->map_check_btf)
> 			return -EINVAL;
> 	}
>
> When btf_key_id is 0, key_type is set to the void type, and
> map->btf_key_type_id is stored as 0. array_map_check_btf() even has a
> dedicated keyless exception ("One exception for keyless BTF:
> .bss/.data/.rodata/.percpu map").
>
> The preceding patch in this series, commit 55f5ad8f45a5 ("bpf: Reject
> key-less BTF for hash maps"), documents a syzbot NULL-ptr-deref where a
> void key reached the map dump path through htab_map_seq_show_elem() ->
> btf_type_seq_show_flags() -> btf_type_show() -> kind_ops[BTF_KIND_UNKN]
> == NULL. That patch closed the path by adding btf_type_is_void(key_type)
> rejections in htab_map_check_btf() and rhtab_map_check_btf().
>
> Would it be more accurate to say the map dump path is closed by the
> preceding patch and by existing btf_key_type_id guards, rather than by
> a size requirement?



I still think I am correct.

A "const void" (a nonzero-id modifier) is rejected as key/value by 
map_check_btf()'s size check;
your key-less case is a bare void key (id 0) on a different path, 
already handled by
patch 1 — so the size reasoning holds here.