linux-kernel - Re: [PATCH] bpf: Don't use %pK through printk

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: <20250813072929-5c7eb9fd-bdc9-4fe3-b885-bfff31def14f@linutronix.de>
Date: Wed, 13 Aug 2025 07:34:34 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, 
	Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, bpf@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bpf: Don't use %pK through printk

On Tue, Aug 12, 2025 at 03:19:45PM -0700, Andrii Nakryiko wrote:
> On Mon, Aug 11, 2025 at 5:08 AM Thomas Weißschuh
> <thomas.weissschuh@...utronix.de> wrote:
> >
> > In the past %pK was preferable to %p as it would not leak raw pointer
> > values into the kernel log.
> > Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
> > the regular %p has been improved to avoid this issue.
> > Furthermore, restricted pointers ("%pK") were never meant to be used
> > through printk(). They can still unintentionally leak raw pointers or
> > acquire sleeping locks in atomic contexts.
> >
> > Switch to the regular pointer formatting which is safer and
> > easier to reason about.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> > ---
> >  include/linux/filter.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/filter.h b/include/linux/filter.h
> > index 1e7fd3ee759e07534eee7d8b48cffa1dfea056fb..52fecb7a1fe36d233328aabbe5eadcbd7e07cc5a 100644
> > --- a/include/linux/filter.h
> > +++ b/include/linux/filter.h
> > @@ -1296,7 +1296,7 @@ void bpf_jit_prog_release_other(struct bpf_prog *fp, struct bpf_prog *fp_other);
> >  static inline void bpf_jit_dump(unsigned int flen, unsigned int proglen,
> >                                 u32 pass, void *image)
> >  {
> > -       pr_err("flen=%u proglen=%u pass=%u image=%pK from=%s pid=%d\n", flen,
> > +       pr_err("flen=%u proglen=%u pass=%u image=%p from=%s pid=%d\n", flen,
> >                proglen, pass, image, current->comm, task_pid_nr(current));
> 
> this particular printk won't ever be called from atomic context, so I
> don't think the leak from atomic context matters much here. On the
> other hand, %pK behavior is controlled by kptr_restrict and that might
> be useful for debugging, so not sure there is much of a benefit to
> switching to always obfuscated %p? Or am I missing something else
> here?

As %pK is so easy to abuse and the breakage is very non-obvious, I want to
rework it to enforce its usage from "file context".
For that, the printk users need to be gone first.
For debugging, there is still "no_hash_pointers".

How would the image pointer be used for debugging?
It is logged from nowhere else.
And the raw image is dumped right after anyways.

> 
> >
> >         if (image)
> >
> > ---
> > base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
> > change-id: 20250811-restricted-pointers-bpf-04da04ea1b8a
> >
> > Best regards,
> > --
> > Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> >