All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next] bpf: Fix offset warn check for bpf_res_spin_lock
Date: Sun, 19 Jul 2026 12:29:36 +0000	[thread overview]
Message-ID: <20260719122937.03FDD1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260719121740.1547434-1-memxor@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unprivileged users can trigger a `WARN_ON_ONCE` in the kernel (causing a panic on systems with `panic_on_warn` enabled) by supplying a crafted BTF with duplicate unique fields hidden inside nested structs.
--

--- Patch [1]: [PATCH bpf-next] bpf: Fix offset warn check for bpf_res_spin_lock ---
commit 5f18853b127e7eb3f89c39c50e8644777d002289
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

bpf: Fix offset warn check for bpf_res_spin_lock

Sashiko pointed out correctly that the case statement for
BPF_RES_SPIN_LOCK incorrectly checks offset for BPF_SPIN_LOCK.
Fix it by checking res_spin_lock_off instead.

> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index cbb1e49b9bcbf..e7d4e9ba24e26 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -4168,7 +4168,7 @@ struct btf_record *btf_parse_fields(const struct btf *btf, const struct btf_type
>  			rec->spin_lock_off = rec->fields[i].offset;
>  			break;
>  		case BPF_RES_SPIN_LOCK:
> -			WARN_ON_ONCE(rec->spin_lock_off >= 0);
> +			WARN_ON_ONCE(rec->res_spin_lock_off >= 0);

[Severity: High]
This is a pre-existing issue, but can unprivileged users trigger this
WARN_ON_ONCE() by supplying a crafted BTF with duplicate unique fields
hidden inside nested structs?

Looking at btf_find_struct_field(), it enforces the uniqueness of special
BTF fields using a local seen_mask variable:

kernel/bpf/btf.c:btf_find_struct_field() {
    ...
    u32 i, off, seen_mask = 0;
    ...
    ret = btf_find_field_one(..., &seen_mask, ...);
    ...
}

However, when it encounters a nested struct, it recursively calls itself
via btf_find_nested_struct(). This nested call initializes a fresh
seen_mask = 0, ignoring the parent's state.

If a user crafts a BTF with multiple nested structs containing duplicate
unique fields (like BPF_SPIN_LOCK or BPF_RES_SPIN_LOCK), wouldn't these
duplicates bypass the seen_mask checks and be returned to
btf_parse_fields()?

Since btf_parse_fields() processes these duplicates and hits this
WARN_ON_ONCE() macro, could this act as a local Denial of Service (DoS)
vector on systems configured with panic_on_warn=1?

>  			/* Cache offset for faster lookup at runtime */
>  			rec->res_spin_lock_off = rec->fields[i].offset;
>  			break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260719121740.1547434-1-memxor@gmail.com?part=1

  reply	other threads:[~2026-07-19 12:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-19 12:17 [PATCH bpf-next] bpf: Fix offset warn check for bpf_res_spin_lock Kumar Kartikeya Dwivedi
2026-07-19 12:29 ` sashiko-bot [this message]
2026-07-20 22:44 ` Emil Tsalapatis

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=20260719122937.03FDD1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=memxor@gmail.com \
    --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.