On Mon, Aug 11, 2025 at 5:08 AM Thomas Weißschuh
<thomas.weissschuh@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxx>
>
