Re: [PATCH bpf-next v4 12/12] kbuild, bpf: allow building the vmlinux BTF as a module

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: unprivileged local DoS via infinite request_module() spam
--

commit 83161d8b7e8e5c9b7cb283e38033cefcc6cf4b26
Author: Jay Wang <wanjay@amazon.com>

kbuild, bpf: allow building the vmlinux BTF as a module

Make CONFIG_DEBUG_INFO_BTF a tristate.  With =m the vmlinux BTF is not
part of the kernel image: it is carried by a new module, btf_vmlinux, and
loaded the first time user space asks for something that needs it.
Otherwise it behaves as with =y, with the exceptions btf.rst lists.

> diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
> index 29de1222c3e73..7d44374b67ba0 100644
> --- a/Documentation/bpf/btf.rst
> +++ b/Documentation/bpf/btf.rst
> @@ -1276,6 +1276,74 @@ format.::
>              .long   58
>              .long   8206                    # Line 8 Col 14
>  
> +6.1 Kernel BTF
> +--------------
> +
> +With CONFIG_DEBUG_INFO_BTF=y the BTF of the kernel is generated at link time
> +from its DWARF and placed in the .BTF section of vmlinux, which is read-only
> +data of the kernel image. It is available as /sys/kernel/btf/vmlinux and, if
> +CONFIG_DEBUG_INFO_BTF_MODULES is set, module BTF is generated as split BTF
> +against it and available as /sys/kernel/btf/<module>.
> +
> +With CONFIG_DEBUG_INFO_BTF=m the same BTF is generated, but it is not part of
> +the kernel image or of the vmlinux ELF file (vmlinux.unstripped in the build
> +tree keeps it, for module BTF generation). It is delivered by the
> +btf_vmlinux module, which the kernel loads the first time user space asks for
> +something that needs the BTF: reading /sys/kernel/btf/vmlinux, enumerating

[Severity: High]
Does this allow an unprivileged local denial of service through infinite
request_module() spam?

If the btf_vmlinux module is missing or fails to load, reading the
world-readable (0444) /sys/kernel/btf/vmlinux sysfs file will continually
trigger request_module() errors.

Since the failure is intentionally not cached:

kernel/bpf/sysfs_btf.c:btf_sysfs_vmlinux_read() {
	...
	void *data = btf_sysfs_vmlinux_load(&size);
	...
}

kernel/bpf/btf.c:btf_vmlinux_data() {
	...
	request_module("%s", btf_vmlinux_link.module_name);
	...
}

Can an unprivileged user loop read() syscalls on this file, bypass the
kmod_concurrent_max limit over time, or sequentially spawn modprobe usermode
helpers thousands of times per second, leading to a CPU/fork bomb effect?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001225214.12351-1-wanjay@amazon.com?part=12