From: sashiko-bot@kernel.org
To: "Nuoqi Gui" <gnq25@mails.tsinghua.edu.cn>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 2/2] selftests/bpf: Cover pseudo-BTF ksym log masking
Date: Tue, 23 Jun 2026 13:05:12 +0000 [thread overview]
Message-ID: <20260623130512.BA0A51F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260623-f01-13-pseudo-btf-id-cap-bpf-v2-2-a190ebb8f3e2@mails.tsinghua.edu.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Unprivileged arbitrary kernel memory read via BPF_PSEUDO_BTF_ID leading to KASLR bypass and data leak.
--
commit 8c947383f7091d6bcf372bba38b8938dbc9b02e4
Author: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
selftests/bpf: Cover pseudo-BTF ksym log masking
This commit adds a selftest to verify that an unprivileged raw socket-filter
can load the bpf_prog_active typed ksym. It ensures the load is accepted
and that the verifier log correctly masks the ldimm64 immediate address.
> diff --git a/tools/testing/selftests/bpf/progs/verifier_unpriv.c b/tools/testing/selftests/bpf/progs/verifier_unpriv.c
> index c16f8382cf17d..16de1595f0157 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_unpriv.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_unpriv.c
[ ... ]
> @@ -77,6 +79,23 @@ __naked void dummy_prog_loop1_socket(void)
> : __clobber_all);
> }
>
> +SEC("socket")
> +__description("unpriv: pseudo btf id log masks address")
> +__success_unpriv
> +__msg_unpriv("0: (18) r1 = 0x0")
> +__not_msg_unpriv("0: (18) r1 = 0x{{[1-9a-f][0-9a-f]*}}")
> +__retval_unpriv(0)
> +__log_level(2)
> +__naked void pseudo_btf_id_log_masks_address(void)
> +{
> + asm volatile ("r1 = %[bpf_prog_active] ll;"
[Severity: Critical]
This is a pre-existing issue, but by validating that unprivileged programs can
successfully load BPF_PSEUDO_BTF_ID instructions against btf_vmlinux, does
this highlight a potential KASLR bypass and kernel memory leak?
When an unprivileged user loads a BPF program using BPF_LD_IMM64 with
src_reg = BPF_PSEUDO_BTF_ID and the BTF ID of a non-struct kernel variable
(such as bpf_prog_active), __check_pseudo_btf_id() assigns the register
type PTR_TO_MEM | MEM_RDONLY:
kernel/bpf/verifier.c:__check_pseudo_btf_id() {
...
aux->btf_var.reg_type = PTR_TO_MEM | MEM_RDONLY;
aux->btf_var.mem_size = tsize;
...
}
If the user then issues a memory read instruction against this register,
check_mem_access() processes PTR_TO_MEM without enforcing
env->allow_ptr_leaks (unlike struct reads in check_ptr_to_btf_access):
kernel/bpf/verifier.c:check_mem_access() {
...
} else if (base_type(reg->type) == PTR_TO_MEM) {
...
if (!err && value_regno >= 0 && (t == BPF_READ || rdonly_mem))
mark_reg_unknown(env, regs, value_regno);
...
}
Could this resulting SCALAR_VALUE then be extracted via maps or return values,
allowing unprivileged attackers to read sensitive non-struct kernel variables?
> + "r0 = 0;"
> + "exit;"
> + :
> + : __imm_addr(bpf_prog_active)
> + : __clobber_all);
> +}
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-f01-13-pseudo-btf-id-cap-bpf-v2-0-a190ebb8f3e2@mails.tsinghua.edu.cn?part=2
prev parent reply other threads:[~2026-06-23 13:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 10:43 [PATCH bpf-next v2 0/2] bpf: Mask pseudo pointer values in verifier logs Nuoqi Gui
2026-06-23 10:43 ` [PATCH bpf-next v2 1/2] " Nuoqi Gui
2026-06-23 11:03 ` sashiko-bot
2026-06-23 10:43 ` [PATCH bpf-next v2 2/2] selftests/bpf: Cover pseudo-BTF ksym log masking Nuoqi Gui
2026-06-23 13:05 ` sashiko-bot [this message]
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=20260623130512.BA0A51F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=gnq25@mails.tsinghua.edu.cn \
--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.