linux-hardening - Re: [PATCH bpf-next v5 08/12] bpf: Report rqspinlock deadlocks/timeout to BPF stderr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <202507301618.ABE8A9BB23@keescook>
Date: Wed, 30 Jul 2025 16:19:23 -0700
From: Kees Cook <kees@...nel.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Kumar Kartikeya Dwivedi <memxor@...il.com>, bpf <bpf@...r.kernel.org>,
	Emil Tsalapatis <emil@...alapatis.com>,
	Alexei Starovoitov <ast@...nel.org>,
	Andrii Nakryiko <andrii@...nel.org>,
	Daniel Borkmann <daniel@...earbox.net>,
	Martin KaFai Lau <martin.lau@...nel.org>,
	Eduard Zingerman <eddyz87@...il.com>,
	Barret Rhoden <brho@...gle.com>,
	Matt Bobrowski <mattbobrowski@...gle.com>, kkd@...a.com,
	Kernel Team <kernel-team@...a.com>, linux-hardening@...r.kernel.org
Subject: Re: [PATCH bpf-next v5 08/12] bpf: Report rqspinlock
 deadlocks/timeout to BPF stderr

On Wed, Jul 30, 2025 at 04:13:25PM -0700, Alexei Starovoitov wrote:
> On Wed, Jul 30, 2025 at 4:09 PM Kees Cook <kees@...nel.org> wrote:
> >
> > On Wed, Jul 30, 2025 at 04:07:33PM -0700, Alexei Starovoitov wrote:
> > > On Wed, Jul 30, 2025 at 4:02 PM Kees Cook <kees@...nel.org> wrote:
> > > >
> > > > On Thu, Jul 03, 2025 at 01:48:14PM -0700, Kumar Kartikeya Dwivedi wrote:
> > > > > +static void bpf_prog_report_rqspinlock_violation(const char *str, void *lock, bool irqsave)
> > > > > +{
> > > > > +     struct rqspinlock_held *rqh = this_cpu_ptr(&rqspinlock_held_locks);
> > > > > +     struct bpf_stream_stage ss;
> > > > > +     struct bpf_prog *prog;
> > > > > +
> > > > > +     prog = bpf_prog_find_from_stack();
> > > > > +     if (!prog)
> > > > > +             return;
> > > > > +     bpf_stream_stage(ss, prog, BPF_STDERR, ({
> > > > > +             bpf_stream_printk(ss, "ERROR: %s for bpf_res_spin_lock%s\n", str, irqsave ? "_irqsave" : "");
> > > > > +             bpf_stream_printk(ss, "Attempted lock   = 0x%px\n", lock);
> > > > > +             bpf_stream_printk(ss, "Total held locks = %d\n", rqh->cnt);
> > > > > +             for (int i = 0; i < min(RES_NR_HELD, rqh->cnt); i++)
> > > > > +                     bpf_stream_printk(ss, "Held lock[%2d] = 0x%px\n", i, rqh->locks[i]);
> > > > > +             bpf_stream_dump_stack(ss);
> > > >
> > > > Please don't include %px in stuff going back to userspace in standard
> > > > error reporting. That's a kernel address leak:
> > > > https://docs.kernel.org/process/deprecated.html#p-format-specifier
> > > >
> > > > I don't see any justification here, please remove the lock address or
> > > > use regular %p to get a hashed value.
> > >
> > > There is no leak here.
> > > The prog was loaded by root and error is read by root.
> >
> > uid has nothing to do with it. Leaking addresses needs the right
> > capability set. Is that always true here?
> 
> yes. For bpf prog to use this kfunc it needs CAP_BPF and CAP_PERMON.
> What's allowed under them is described in include/uapi/linux/capability.h

Okay, thanks! That wasn't detailed in the commit log (for folks like me
with less familiarity with BPF), so I just got worried when I saw
"stderr" mentioned. :)

-- 
Kees Cook