From: Petr Mladek <pmladek@suse.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Kees Cook <kees@kernel.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Tycho Andersen <tycho@tycho.pizza>,
Namhyung Kim <namhyung@kernel.org>
Subject: Re: [PATCH v5 0/2] vsprintf: Don't leak pointers
Date: Tue, 3 Nov 2026 15:10:59 +0100 [thread overview]
Message-ID: <aunrc5atzlyf0TM9@pathway.suse.cz> (raw)
In-Reply-To: <20261023-vsprintf_kallsym-v5-0-57ff92187c1d@linutronix.de>
On Fri 2026-10-23 18:46:22, Sebastian Andrzej Siewior wrote:
> It is possible to leak pointers via %ps without KALLSYMS enabled.
> With KALLSYMS pointers can be leaked if they can not be resolved.
>
> The tiny series has two patches, one for each issue.
> I do follow the %p format instead of printing "(unknown)" since I care
> more about getting it out of the way than the actual content (as long as
> it is not the leaked pointer). Last time the discussion added the h:
> prefix to a hashed pointer to identify it as such. I would like to keep
> this part out of the series since there are few users that expect a
> certain pointer width and adding two extra characters would break that
> (we could strip the two 0 on 64bit but again, not related to this
> problem here).
>
> v4…v5: https://patch.msgid.link/20261019-vsprintf_kallsym-v4-0-ffd3c012d00c@linutronix.de
> - Use %p instead snprintf_default_pointer(). This might recurse back to
> vsnprintf() if used by '%ps' but it already did so. Suggested by Petr
> Mladek.
>
> v3…v4: https://patch.msgid.link/20261015-vsprintf_kallsym-v3-0-c175c27f38b7@linutronix.de
> - In symbol_string(), !CONFIG_KALLSYMS case, use the 'value' argument
> instead 'ptr' to consider the '%pR' case. Noticed by lkp@intel.com.
> - The kerneldoc for snprintf_default_pointer() must describe the 'len'
> argument instead the not existing 'size'. Noticed by lkp@intel.com.
> - sashiko noticed that the string isn't properly terminated if the
> input buffer is too small.
>
> v2…v3: https://lore.kernel.org/all/20260821152614.2202196-1-bigeasy@linutronix.de/
> - Instead of "(unknown)" the hashed pointer is printed. This follows
> the generic %p flow.
> - In v2 I argued that it is better so print the actual pointer instead
> hiding it for post-mortem analysis. After looking at some backtraces
> with invalid pointers (not part of the kernel image) I realised the
> the PC is already part of the register dump. There I changed it back
> to what %p would do if it can't resolve a pointer. Again, following
> %p flow so it can be overridden at boot.
>
> v1…v2: https://lore.kernel.org/all/20260814144854.746840-1-bigeasy@linutronix.de/
> - For %ps and !KALLSYMS no_hash_pointers is used to decide if the
> pointer should be written or not. This aligns with the %p policy.
> - For %ps and KALLSYMS, unresolved pointer continue to be leaked. It
> has been pointed out it might be useful to see them in backtraces/
> crashes if the return address became invalid.
>
> ---
> Sebastian Andrzej Siewior (2):
> vsprintf: Don't leak pointers for %ps without KALLSYMS enabled
> kallsyms: Don't leak pointers for unresolved symbols
>
> kernel/kallsyms.c | 2 +-
> lib/vsprintf.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
JFYI, the patchset has been committed into printk/linux.git,
branch for-7.5-vsprintf-kallsyms.
Best Regards,
Petr
next prev parent reply other threads:[~2026-11-03 14:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 16:46 [PATCH v5 0/2] vsprintf: Don't leak pointers Sebastian Andrzej Siewior
2026-10-23 16:46 ` [PATCH v5 1/2] vsprintf: Don't leak pointers for %ps without KALLSYMS enabled Sebastian Andrzej Siewior
2026-10-23 16:46 ` [PATCH v5 2/2] kallsyms: Don't leak pointers for unresolved symbols Sebastian Andrzej Siewior
2026-10-24 2:13 ` kernel test robot
2026-10-24 10:07 ` Andy Shevchenko
2026-10-24 16:10 ` Sebastian Andrzej Siewior
2026-10-25 14:51 ` Andy Shevchenko
2026-10-27 16:00 ` Petr Mladek
2026-11-02 11:38 ` Sebastian Andrzej Siewior
2026-11-03 14:10 ` Petr Mladek [this message]
2026-11-03 15:45 ` [PATCH v5 0/2] vsprintf: Don't leak pointers Sebastian Andrzej Siewior
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=aunrc5atzlyf0TM9@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bigeasy@linutronix.de \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=namhyung@kernel.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tycho@tycho.pizza \
/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.