Re: [PATCH v3 bpf-next 3/7] kbuild, btf: Expose vmlinux inline BTF through sysfs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] bpf: btf: Unvalidated zero-size allocation triggers WARN_ON_ONCE in vmalloc_user
- [Low] bpf: btf: Linkage fails for sha256 when CONFIG_DEBUG_INFO_BTF_INLINE=m
--

commit de2bb52fc001c93d461a0839a26e550f67f5ecc2
Author: Alan Maguire <alan.maguire@oracle.com>

kbuild, btf: Expose vmlinux inline BTF through sysfs

This commit introduces support for embedded and module-delivered vmlinux
inline BTF payloads, making them available via sysfs. It also sets up deferred
binding for a module-provided .BTF.inline section.

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 134b15a44625e..24abfff1ddc3c 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -432,6 +438,19 @@ config DEBUG_INFO_BTF_MODULES
>  	help
>  	  Generate compact split BTF type information for kernel modules.
>  
> +config DEBUG_INFO_BTF_INLINE
> +	tristate "Provide information about inline sites in BTF"
> +	default n
> +	depends on DEBUG_INFO_BTF && PAHOLE_HAS_INLINE && SYSFS
> +	select DEBUG_INFO_BTF_MODULES if MODULES
> +	select CRYPTO_LIB_SHA256

[Severity: Low]
Does this cause a linkage failure when CONFIG_DEBUG_INFO_BTF_INLINE is built
as a module?

Because this is a tristate, selecting CRYPTO_LIB_SHA256 here means it will 
evaluate to 'm' if the inline feature is configured as a module. 

However, the crypto library is called directly from the built-in core kernel
object kernel/bpf/btf.c:

kernel/bpf/btf.c:btf_verify_link() {
    ...
    sha256(data, data_size, actual_digest);
    ...
}

A built-in object cannot resolve a symbol exported by a loadable module,
which will result in an 'undefined reference to sha256' error at build time.

> +	help
> +	  Generate information about inline sites in .BTF.inline sections.

[ ... ]

> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 0630675377aaa..732ba06846675 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c

[ ... ]

> @@ -9015,21 +9016,122 @@ static DEFINE_MUTEX(btf_module_mutex);
> +static int btf_module_handle_vmlinux_inline(const struct module *mod)
> +{
> +	void *data = NULL;
> +
> +	if (!vmlinux_inline_link || strcmp(mod->name, vmlinux_inline_link->module_name))
> +		return -ENOENT;
> +
> +	data = vmalloc_user(mod->btf_inline_data_size);

[Severity: Medium]
Could this trigger a WARN_ON_ONCE splat in the memory allocation paths?

If a user with CAP_SYS_MODULE loads a module matching
vmlinux_inline_link->module_name, but the module has no .BTF.inline section
(or its size is exactly 0), mod->btf_inline_data_size will be set to 0.

Calling vmalloc_user(0) here happens before the size is validated against 
link->btf_size, which causes a kernel warning in __vmalloc_node_range_noprof.

> +	if (!data)
> +		return -ENOMEM;
> +	memcpy(data, mod->btf_inline_data, mod->btf_inline_data_size);
> +
> +	if (!btf_verify_link(vmlinux_inline_link, mod, data, mod->btf_inline_data_size) ||
> +	    !sysfs_btf_update(vmlinux_inline_attr, data)) {
> +		kvfree(data);
> +		return -EINVAL;
> +	}
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261003194323.817885-1-alan.maguire@oracle.com?part=3