Re: [PATCH bpf v2 1/4] bpf: Reject key-less BTF for hash maps

[bot+bpf-ci]

> map_check_btf() allows a key-less BTF (btf_key_type_id == 0) only for
> maps that have a ->map_check_btf callback, and leaves the actual
> decision to that callback. Hash maps used to have no ->map_check_btf,
> so a key-less BTF was rejected outright.
>
> Since commit 1df97a7453ee ("bpf: Register dtor for freeing special
> fields") htab and rhtab got a ->map_check_btf to register a dtor, but
> it does not look at the key, so a key-less hash map now passes
> map_check_btf() and gets created.

Is this attribution accurate? Commit 1df97a7453ee did add
htab_map_check_btf() to the four htab ops structs (htab_map_ops,
htab_lru_map_ops, htab_percpu_map_ops, htab_lru_percpu_map_ops), but
BPF_MAP_TYPE_RHASH did not exist at that commit.

The rhtab regression was introduced three months later by the second
Fixes: commit 6905f8601298 ("bpf: Allow special fields in resizable
hashtab"), which added rhtab_map_check_btf() and rhtab_map_ops for the
first time.

Could the commit message distinguish which regression each Fixes: tag
addresses? As written, the sentence attributes both regressions to
1df97a7453ee.

> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
> RIP: 0010:btf_type_show (kernel/bpf/btf.c:8251)
> Call Trace:
>  <TASK>
>  btf_type_seq_show_flags (kernel/bpf/btf.c:8269)
>  btf_type_seq_show (kernel/bpf/btf.c:8277)
>  htab_map_seq_show_elem (kernel/bpf/hashtab.c:1669)
>  map_seq_show (kernel/bpf/inode.c:293)
>  seq_read_iter (fs/seq_file.c:273)
>  seq_read (fs/seq_file.c:163)
>  vfs_read (fs/read_write.c:572)
>  ksys_read (fs/read_write.c:716)
>  __x64_sys_read (fs/read_write.c:725)
>  do_syscall_64 (arch/x86/entry/syscall_64.c:61)
>  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
>  </TASK>

Does this match the syzbot report? Looking at the actual report at the
Closes: link, several details differ from what was quoted:

The syscall in the report was pread64:
  ksys_pread64 [inline]
  __x64_sys_pread64+0x1eb/0x250 fs/read_write.c:769

But the quoted trace shows read (ksys_read, __x64_sys_read).

The report shows traverse() frames that are missing here:
  traverse.part.0 fs/seq_file.c:112
  traverse fs/seq_file.c:99 [inline]
  seq_read_iter+0x93f/0x1270 fs/seq_file.c:196

And seq_read_iter's line number is 196 in the report, not 273.

There is an extra btf_type_seq_show frame inserted here that is not in
the report.

The btf.c line numbers are shifted by +19: the report shows
btf_type_show at 8232, btf_type_seq_show_flags at 8250, and
btf_type_seq_show at 8258, but the quoted trace adds 19 to each.

Should the crash trace be quoted verbatim from the syzbot report rather
than edited?


---
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/33300136294