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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQLbgXxUROzhKhdK8v+2Z4f5nqV34rHMn2Q0PebUo+VqyQ@mail.gmail.com>
Date: Wed, 30 Jul 2025 16:13:25 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Kees Cook <kees@...nel.org>
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 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