在 8/31/26 7:48 PM, [email protected] 写道:
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.
