From: sashiko-bot@kernel.org
To: "Alan Maguire" <alan.maguire@oracle.com>
Cc: linux-modules@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 16/18] btf: Relocate inline BTF for modules with distilled base BTF
Date: Tue, 01 Sep 2026 17:29:57 +0000 [thread overview]
Message-ID: <20260901172958.316581F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260901165757.801449-17-alan.maguire@oracle.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Kernel panic via unconditional btf_free(NULL) on error path
- [Medium] Memory leak of vmlinux.inline sysfs attribute data across module unloads and reloads
- [Medium] Concurrent updates and reads of `vmlinux.inline` BTF sysfs data can cause an out-of-bounds read
--
commit aad19c968ab1d821749bb6d06563d7c786f0721d
Author: Alan Maguire <alan.maguire@oracle.com>
btf: Relocate inline BTF for modules with distilled base BTF
This commit adds support for parsing, relocating, and publishing inline BTF
for modules that use a distilled base BTF. It parses the module's inline
BTF relative to the original module BTF, rewrites the IDs and string
offsets, and ensures a failure to process inline BTF doesn't block the
regular module BTF registration.
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 2ac1f1d396608..2f3e8cea7dfcd 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
[ ... ]
> @@ -6727,15 +6727,140 @@ __u32 btf_relocate_id(const struct btf *btf, __u32 id)
[ ... ]
> errout:
> + kvfree(module_str_map);
> btf_verifier_env_free(env);
> + btf_free(inline_btf);
> if (!IS_ERR(base_btf) && base_btf != vmlinux_btf)
> btf_free(base_btf);
> - if (btf) {
> - kvfree(btf->data);
> - kvfree(btf->types);
> - kfree(btf);
> - }
> + btf_free(btf);
[Severity: High]
Is it safe to unconditionally call btf_free() on these pointers here?
If btf_parse_split() returns an error, btf or inline_btf can be NULL before
jumping to errout. Looking at btf_free(), it immediately passes the pointer
to btf_free_struct_meta_tab(), which dereferences it without checking for
NULL:
static void btf_free(struct btf *btf)
{
btf_free_struct_meta_tab(btf);
...
static void btf_free_struct_meta_tab(struct btf *btf)
{
struct btf_struct_metas *tab = btf->struct_meta_tab;
Could this lead to a NULL pointer dereference and a kernel panic during an
error path?
> return ERR_PTR(err);
> }
[ ... ]
> @@ -8958,32 +9104,26 @@ static int btf_module_notify(struct notifier_block *nb, unsigned long op,
> btf_mod->sysfs_attr = attr;
>
> #if IS_ENABLED(CONFIG_DEBUG_INFO_BTF_INLINE)
> - if (mod->btf_inline_data_size > 0) {
> + if (relocated_inline_data) {
> char name[MODULE_NAME_LEN + sizeof(".inline")];
>
> if (strcmp(mod->name, "btf_vmlinux_inline") == 0) {
> if (vmlinux_inline_attr)
> - sysfs_btf_update(vmlinux_inline_attr, data,
> - mod->btf_inline_data_size);
> + sysfs_btf_update(vmlinux_inline_attr,
> + relocated_inline_data, inline_data_size);
[Severity: Medium]
Could the concurrent update of this sysfs attribute cause an out-of-bounds
read?
Looking at sysfs_btf_update(), the new pointer is written before the new
size:
static void sysfs_btf_update(struct bin_attribute *attr, void *data,
size_t data_size)
{
...
WRITE_ONCE(attr->private, data);
smp_store_release(&attr->size, data_size);
}
If a concurrent reader in sysfs_btf_kernfs_read() picks up the old, larger
size via smp_load_acquire(), but then reads the newly updated pointer from
attr->private via READ_ONCE(), wouldn't the subsequent memcpy() read
out-of-bounds past the end of the new, smaller data buffer?
> else
> - kvfree(data);
> + kvfree(relocated_inline_data);
> + btf_mod->btf_inline_data = NULL;
[Severity: Medium]
Does setting btf_mod->btf_inline_data to NULL here cause a memory leak when
the btf_vmlinux_inline module is unloaded?
Because it's set to NULL, the normal cleanup path in btf_module_notify()
won't free it. Then, if the module is reloaded, sysfs_btf_update() will
overwrite the vmlinux_inline_attr->private pointer with a new allocation,
leaving the old relocated_inline_data stranded.
> break;
> }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260901165757.801449-1-alan.maguire@oracle.com?part=16
next prev parent reply other threads:[~2026-09-01 17:29 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 16:57 [PATCH v2 bpf-next 00/18] Support inline functions in BTF Alan Maguire
2026-09-01 16:57 ` [PATCH v2 bpf-next 01/18] btf: Extend UAPI to support BTF location (inline site) info Alan Maguire
2026-09-01 17:17 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
2026-09-09 22:26 ` Eduard Zingerman
2026-09-11 19:26 ` Jiri Olsa
2026-09-01 16:57 ` [PATCH v2 bpf-next 02/18] libbpf: Add support for BTF kinds LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-01 17:11 ` sashiko-bot
2026-09-09 22:26 ` Eduard Zingerman
2026-09-01 16:57 ` [PATCH v2 bpf-next 03/18] libbpf: Support moving permuted BTF types into split BTF Alan Maguire
2026-09-01 17:15 ` sashiko-bot
2026-09-01 18:14 ` bot+bpf-ci
2026-09-10 9:37 ` Eduard Zingerman
2026-09-01 16:57 ` [PATCH v2 bpf-next 04/18] selftests/bpf: Test helper support for BTF_KIND_LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-01 17:06 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 05/18] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to field iter tests Alan Maguire
2026-09-01 16:57 ` [PATCH v2 bpf-next 06/18] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to dedup split tests Alan Maguire
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 07/18] selftests/bpf: BTF distill tests to ensure LOC[_PARAM|_PROTO] add to split BTF Alan Maguire
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 08/18] selftests/bpf: Validate that btf__permute transfer works Alan Maguire
2026-09-01 17:16 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 09/18] bpftool: Handle multi-split BTF by supporting multiple base BTFs Alan Maguire
2026-09-01 17:13 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 10/18] bpftool: Document support for multi-split BTF Alan Maguire
2026-09-01 17:12 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 11/18] bpftool: Add ability to dump LOC_PARAM, LOC_PROTO and LOCSEC Alan Maguire
2026-09-01 17:16 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
2026-09-07 19:30 ` Alexei Starovoitov
2026-09-01 16:57 ` [PATCH v2 bpf-next 12/18] resolve_btfids: Extract inline BTF Alan Maguire
2026-09-01 17:23 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 13/18] kbuild: Add support for BTF inline information Alan Maguire
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 14/18] btf: Make vmlinux, module inline info available in /sys/kernel/btf Alan Maguire
2026-09-07 19:34 ` Alexei Starovoitov
2026-09-07 19:50 ` Alan Maguire
2026-09-07 20:00 ` Alexei Starovoitov
2026-09-01 16:57 ` [PATCH v2 bpf-next 15/18] btf: Support CONFIG_DEBUG_INFO_BTF_INLINE=m Alan Maguire
2026-09-01 17:24 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 16/18] btf: Relocate inline BTF for modules with distilled base BTF Alan Maguire
2026-09-01 17:29 ` sashiko-bot [this message]
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 17/18] selftests/bpf: Test BTF sysfs inline representations Alan Maguire
2026-09-01 17:22 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 18/18] selftests/bpf: Add a test verifying inline information Alan Maguire
2026-09-01 17:28 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260901172958.316581F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=bpf@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.