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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250224150920-87b1bf56-9520-4cd1-ab51-93da2eece162@linutronix.de>
Date: Mon, 24 Feb 2025 15:12:54 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Will Deacon <will@...nel.org>
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 Fri, Feb 21, 2025 at 02:55:14PM +0000, Will Deacon wrote:
> 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_.

That makes sense, especially the value being part of the register dump.
OTOH in the default kernel configuration (kptr_restrict==0), %pK is an alias to
%p and also hashing the pointers. And so far nobody seems to have cared.

If you prefer I can also change it to %px, to specifically show the value.
My main goal is to remove %pK, as it's prone to misuse.


Thomas