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: <CAEf4Bzb7DFwvh6J8sPv34U+M=prFKQ8QZiJAk2SE5hPvy7DG1g@mail.gmail.com>
Date: Tue, 12 Aug 2025 15:19:45 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
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 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?

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