From: sashiko-bot@kernel.org
To: "Nuoqi Gui" <gnq25@mails.tsinghua.edu.cn>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 1/2] bpf: Mask pseudo pointer values in verifier logs
Date: Tue, 23 Jun 2026 11:03:43 +0000 [thread overview]
Message-ID: <20260623110345.0A6751F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260623-f01-13-pseudo-btf-id-cap-bpf-v2-1-a190ebb8f3e2@mails.tsinghua.edu.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Translated BPF program dump (BPF_OBJ_GET_INFO_BY_FD) leaks physical kernel addresses from BPF_PSEUDO_BTF_ID instructions to users without CAP_PERFMON.
--
commit 302eadb037a969e2a3c9dbab8e1a08cf49f16888
Author: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
bpf: Mask pseudo pointer values in verifier logs
This commit updates print_bpf_insn() to mask additional pointer-bearing
pseudo sources like BPF_PSEUDO_BTF_ID in verifier logs when pointer leaks
are not allowed.
> diff --git a/kernel/bpf/disasm.c b/kernel/bpf/disasm.c
> index f8a3c7eb451e4..0391b3bc00734 100644
> --- a/kernel/bpf/disasm.c
> +++ b/kernel/bpf/disasm.c
> @@ -323,7 +323,10 @@ void print_bpf_insn(const struct bpf_insn_cbs *cbs,
> */
> u64 imm = ((u64)(insn + 1)->imm << 32) | (u32)insn->imm;
> bool is_ptr = insn->src_reg == BPF_PSEUDO_MAP_FD ||
> - insn->src_reg == BPF_PSEUDO_MAP_VALUE;
> + insn->src_reg == BPF_PSEUDO_MAP_VALUE ||
> + insn->src_reg == BPF_PSEUDO_MAP_IDX ||
> + insn->src_reg == BPF_PSEUDO_MAP_IDX_VALUE ||
> + insn->src_reg == BPF_PSEUDO_BTF_ID;
[Severity: High]
This isn't a bug introduced by this patch, but does the kernel still leak
physical addresses from BPF_PSEUDO_BTF_ID instructions when a user without
CAP_PERFMON calls BPF_OBJ_GET_INFO_BY_FD to dump the translated program?
In kernel/bpf/verifier.c:convert_pseudo_ld_imm64(), the verifier clears
the src_reg for non-func pseudo loads after resolving the address:
if (insn->src_reg == BPF_PSEUDO_FUNC)
continue;
insn->src_reg = 0;
Later, when dumping the instructions in
kernel/bpf/syscall.c:bpf_insn_prepare_dump():
imm = ((u64)insns[i + 1].imm << 32) | (u32)insns[i].imm;
map = bpf_map_from_imm(prog, imm, &off, &type);
if (map) {
insns[i].src_reg = type;
insns[i].imm = map->id;
insns[i + 1].imm = off;
continue;
}
Because BPF_PSEUDO_BTF_ID resolves to a kernel symbol rather than a map,
bpf_map_from_imm() returns NULL. Since src_reg was zeroed by the verifier,
this code has no way to distinguish the leaked physical kernel address from
a normal 64-bit constant.
Could this allow users to retrieve raw kernel pointers, since there is no
fallback bpf_dump_raw_ok(f_cred) check here?
> char tmp[64];
>
> if (is_ptr && !allow_ptr_leaks)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-f01-13-pseudo-btf-id-cap-bpf-v2-0-a190ebb8f3e2@mails.tsinghua.edu.cn?part=1
next prev parent reply other threads:[~2026-06-23 11:03 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 [this message]
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
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=20260623110345.0A6751F00A3A@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox