linux-kernel - Re: [PATCH net-next 0/7] net: 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: <20250415084250-8f385935-6e23-447d-8e94-3170d0d3ec9f@linutronix.de>
Date: Tue, 15 Apr 2025 08:59:41 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Brian Norris <briannorris@...omium.org>
Cc: Jeff Johnson <jjohnson@...nel.org>, 
	Loic Poulain <loic.poulain@...aro.org>, Francesco Dolcini <francesco@...cini.it>, 
	Tony Nguyen <anthony.l.nguyen@...el.com>, Przemek Kitszel <przemyslaw.kitszel@...el.com>, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Saeed Mahameed <saeedm@...dia.com>, 
	Leon Romanovsky <leon@...nel.org>, Tariq Toukan <tariqt@...dia.com>, ath10k@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, ath11k@...ts.infradead.org, ath12k@...ts.infradead.org, 
	wcn36xx@...ts.infradead.org, linux-wireless@...r.kernel.org, intel-wired-lan@...ts.osuosl.org, 
	netdev@...r.kernel.org, linux-rdma@...r.kernel.org
Subject: Re: [PATCH net-next 0/7] net: Don't use %pK through printk

On Mon, Apr 14, 2025 at 11:44:24AM -0700, Brian Norris wrote:
> On Mon, Apr 14, 2025 at 10:26:01AM +0200, Thomas Weißschuh wrote:
> > Furthermore, restricted pointers ("%pK") were never meant to be used
> > through printk().
> 
> Is this really true? Documentation/admin-guide/sysctl/kernel.rst still
> has a section on kptr_restrict which talks about dmesg, CAP_SYSLOG, and
> %pK, which sounds like it's intended. But I'm not highly familiar with
> this space, so maybe I'm misreading something.

The wording about dmesg, etc was added in
commit 312b4e226951 ("vsprintf: check real user/group id for %pK").

Its commit message also notes:

    This is a only temporary solution to the issue.  The correct solution is
    to do the permission check at open() time on files, and to replace %pK
    with a function which checks the open() time permission.  %pK uses in
    printk should be removed since no sane permission check can be done, and
    instead protected by using dmesg_restrict.

Doing this is my goal. One of the later steps is to replace %pK completely.
Probably with a function similar to kallsyms_show_value().

> (I do see that commit a48849e2358e ("printk: clarify the documentation
> for plain pointer printing") updated
> Documentation/core-api/printk-formats.rst.)
> 
> In any case, even if the advice has changed, it seems (again, to an
> outsider) a bit much to say it was "never" meant to be used through
> printk().

IMO "never" is correct. Using %pK through printk() was only ever a bandaid to
get at least some of the security benefits of hashed pointers.


Thomas