linux-kernel - Re: [PATCH] arm64: mm: 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250221145513.GA20567@willie-the-truck>
Date: Fri, 21 Feb 2025 14:55:14 +0000
From: Will Deacon <will@...nel.org>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Catalin Marinas <catalin.marinas@....com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: mm: Don't use %pK through printk

On Mon, Feb 17, 2025 at 08:39:06AM +0100, Thomas Weißschuh wrote:
> Restricted pointers ("%pK") are not meant to be used through printk().
> It can unintentionally expose security sensitive, raw pointer values.
> 
> Use regular pointer formatting instead.
> 
> Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> ---
>  arch/arm64/mm/physaddr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
> index cde44c13dda1bc0924d2d50369ad87f544a0a802..7d94e09b01b35094e883875a46b979666549095c 100644
> --- a/arch/arm64/mm/physaddr.c
> +++ b/arch/arm64/mm/physaddr.c
> @@ -10,7 +10,7 @@
>  phys_addr_t __virt_to_phys(unsigned long x)
>  {
>  	WARN(!__is_lm_address(__tag_reset(x)),
> -	     "virt_to_phys used for non-linear address: %pK (%pS)\n",
> +	     "virt_to_phys used for non-linear address: %p (%pS)\n",
>  	      (void *)x,
>  	      (void *)x);

This is part of a WARN() and knowing the actual address may well be
useful in debugging. I suspect it also ends up being dumped as part of
the register dump _anyway_.

Will