1. Patchew
  2. linux
  3. View series

[PATCH] bpf: Don't use %pK through printk

Thomas Weißschuh posted 1 patch 1 month, 3 weeks ago 
include/linux/filter.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] bpf: Don't use %pK through printk
Posted by Thomas Weißschuh 1 month, 3 weeks ago 
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@linutronix.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));
 
 	if (image)

---
base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
change-id: 20250811-restricted-pointers-bpf-04da04ea1b8a

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Re: [PATCH] bpf: Don't use %pK through printk
Posted by Andrii Nakryiko 1 month, 3 weeks ago 
On Mon, Aug 11, 2025 at 5:08 AM Thomas Weißschuh
<thomas.weissschuh@linutronix.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@linutronix.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?

>
>         if (image)
>
> ---
> base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
> change-id: 20250811-restricted-pointers-bpf-04da04ea1b8a
>
> Best regards,
> --
> Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>
Re: [PATCH] bpf: Don't use %pK through printk
Posted by Thomas Weißschuh 1 month, 3 weeks ago 
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@linutronix.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@linutronix.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@linutronix.de>
> >
Re: [PATCH] bpf: Don't use %pK through printk
Posted by Andrii Nakryiko 1 month, 3 weeks ago 
On Tue, Aug 12, 2025 at 10:34 PM Thomas Weißschuh
<thomas.weissschuh@linutronix.de> wrote:
>
> 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@linutronix.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@linutronix.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?

I chatted with Daniel about this offline, and it seems like this is
not that critical nowadays. So I went ahead and applied the patch to
bpf-next.

> 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@linutronix.de>
> > >

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.