[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <118316e45268be4d98f96f1f1ca0c337e97ea579.camel@kernel.org>
Date: Thu, 31 Jul 2025 15:01:28 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Jakub Kicinski
<kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ref_tracker: use %p instead of %px in debugfs dentry
name
On Thu, 2025-07-31 at 09:32 -0700, Kees Cook wrote:
> On Thu, Jul 31, 2025 at 07:57:05AM -0400, Jeff Layton wrote:
> > As Kees points out, this is a kernel address leak, and debugging is
> > not a sufficiently good reason to expose the real kernel address.
> >
> > Fixes: 65b584f53611 ("ref_tracker: automatically register a file in debugfs for a ref_tracker_dir")
> > Reported-by: Kees Cook <kees@...nel.org>
> > Closes: https://lore.kernel.org/netdev/202507301603.62E553F93@keescook/
> > Signed-off-by: Jeff Layton <jlayton@...nel.org>
>
> Probably better to use a global u64 counter, but %p can work.
>
I disagree here, again for debugging purposes...
Other kernel debugging code can display a hashed pointer via tracepoint
or printk message, etc. Using the same value in the name here gives us
a mechanism to match that up to the correct debugfs file.
Using a counter would make that harder, and you'd have to store the
counter value in the object (or reach into the dentry -- yuck).
Plus if we _really_ need the physical addresses here in the future, we
can boot with no_hash_pointers and get them.
> Thanks for removing %px!
Thanks for pointing out the problem!
--
Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists