> 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?

> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -2911,7 +2911,15 @@ static void btf_modifier_show(const struct btf *btf,
>       else
>               t = btf_type_skip_modifiers(btf, type_id, NULL);
>
> -     btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);
> +     /*
> +      * A modifier can resolve to the void type (e.g. "const void"), which
> +      * has no show op (kind_ops[BTF_KIND_UNKN] is NULL). Print a placeholder
> +      * instead of dereferencing NULL.
> +      */
> +     if (!btf_type_ops(t))
> +             btf_df_show(btf, t, type_id, data, bits_offset, show);
> +     else
> +             btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);
>  }
>
>  static void btf_var_show(const struct btf *btf, const struct btf_type *t,


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33385673160

Reply via email to