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

That changed when htab and rhtab gained a ->map_check_btf to register a
dtor - htab in commit 1df97a7453ee ("bpf: Register dtor for freeing
special fields") and rhtab in commit 6905f8601298 ("bpf: Allow special
fields in resizable hashtab"). Neither looks at the key, so a key-less
hash map now passes map_check_btf() and gets created. Reading it back
through bpffs feeds the key type_id 0 into btf_type_seq_show();
btf_type_by_id() returns the void type, kind_ops[BTF_KIND_UNKN] is NULL,
and btf_type_show() dereferences it:

KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
RIP: 0010:btf_type_show+0x223/0x2e0 kernel/bpf/btf.c:8232
Call Trace:
  <TASK>
  btf_type_seq_show_flags+0xca/0x120 kernel/bpf/btf.c:8250
  htab_map_seq_show_elem+0x12e/0x350 kernel/bpf/hashtab.c:1669
  map_seq_show+0x13d/0x1e0 kernel/bpf/inode.c:293
  seq_read_iter+0x93f/0x1270 fs/seq_file.c:196
  seq_read+0x344/0x4d0 fs/seq_file.c:163
  vfs_read+0x1e4/0xb40 fs/read_write.c:572
  __x64_sys_pread64+0x1eb/0x250 fs/read_write.c:769
  do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
  </TASK>
The call trace appears to be edited from the original syzbot report.
The original report ([email protected])
includes these additional frames between map_seq_show and seq_read_iter:

   traverse.part.0.constprop.0+0x107/0x650 fs/seq_file.c:112
   traverse fs/seq_file.c:99 [inline]

and also includes the inline frames for the pread64 syscall path:

   ksys_pread64 fs/read_write.c:760 [inline]
   __do_sys_pread64 fs/read_write.c:769 [inline]
   __se_sys_pread64 fs/read_write.c:766 [inline]


I edited it intentional‌ly to avoid breaking the format rule.



Reply via email to