From: sashiko-bot@kernel.org
To: "Sebastian Andrzej Siewior" <bigeasy@linutronix.de>
Cc: "Marc Kleine-Budde" <mkl@pengutronix.de>,
"Oliver Hartkopp" <socketcan@hartkopp.net>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
linux-can@vger.kernel.org, "Vincent Mailhol" <mailhol@kernel.org>
Subject: Re: [PATCH net-next] net: Convert %pK back to %p
Date: Tue, 07 Jul 2026 07:46:53 +0000 [thread overview]
Message-ID: <20260707074654.325F01F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260706073824.xixrLxoD@linutronix.de>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Replacing `%pK` with `%p` breaks userspace tracing ABI and `kptr_restrict` runtime configurability.
- [Medium] Incomplete refactoring misses `net/bluetooth/af_bluetooth.c`, leaving inconsistent pointer formatting behavior.
--
commit b2c57f416d95fe882e14b5fd13915b835f475930
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
net: Convert %pK back to %p
This commit reverts a 2011 change that converted %p usage to %pK in the
networking subsystem. It replaces %pK with %p across various procfs output
files, stating that %p now defaults to a hashed pointer anyway.
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 209ef7522508f..aa31af06e5e3b 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
[ ... ]
> @@ -2806,7 +2806,7 @@ static void get_tcp4_sock(struct sock *sk, struct seq_file *f, int i)
> READ_ONCE(tp->copied_seq), 0);
>
> seq_printf(f, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX "
> - "%08X %5u %8d %llu %d %pK %lu %lu %u %u %d",
> + "%08X %5u %8d %llu %d %p %lu %lu %u %u %d",
[Severity: Critical]
Does replacing %pK with %p in get_tcp4_sock() break the userspace tracing
ABI and bypass the kernel.kptr_restrict sysctl?
Under kptr_restrict=1 (the default on most distributions), %pK returns the
raw kernel pointer to users with the syslog capability. By reverting to %p,
a hashed pointer is unconditionally returned instead.
While the commit message notes that hash_pointers can be disabled at boot,
does this break the runtime configurability provided by the
kernel.kptr_restrict sysctl?
Will existing tracing tools that correlate /proc sockets with kernel memory
receive hashes and fail instead of raw pointers?
[ ... ]
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index f7a9d55eee8a1..6a8174977c87a 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
[ ... ]
> @@ -3554,7 +3554,7 @@ static int unix_seq_show(struct seq_file *seq, void *v)
> struct unix_sock *u = unix_sk(s);
> unix_state_lock(s);
>
> - seq_printf(seq, "%pK: %08X %08X %08X %04X %02X %5llu",
> + seq_printf(seq, "%p: %08X %08X %08X %04X %02X %5llu",
[Severity: Critical]
Does this also expose unix socket structures directly as hashed pointers in
unix_seq_show(), bypassing sysctl restrictions?
Similar to the tcp change above, will tracing tools no longer be able to
resolve these pointers when kptr_restrict=1 is set?
[ ... ]
[Severity: Medium]
Does this commit leave the networking subsystem in an inconsistent state by
missing net/bluetooth/af_bluetooth.c?
Looking at bt_seq_show() in net/bluetooth/af_bluetooth.c, it still uses %pK:
seq_printf(f, "%pK %-6d %-6u %-6u %-6u %-6llu %-6llu",
Is this the only remaining use of %pK in the net/ subsystem that was missed
by the refactoring? This appears to leave bluetooth procfs files respecting
kptr_restrict while the other protocols do not.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706073824.xixrLxoD@linutronix.de?part=1
next prev parent reply other threads:[~2026-07-07 7:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 7:38 [PATCH net-next] net: Convert %pK back to %p Sebastian Andrzej Siewior
2026-07-07 7:46 ` sashiko-bot [this message]
2026-07-07 9:37 ` Sebastian Andrzej Siewior
2026-07-09 11:28 ` Petr Mladek
2026-07-09 16:18 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260707074654.325F01F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mkl@pengutronix.de \
--cc=o.rempel@pengutronix.de \
--cc=sashiko-reviews@lists.linux.dev \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.