All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting
Date: Wed, 18 Mar 2026 12:01:15 +0100	[thread overview]
Message-ID: <abqF-37LT_D8WWtC@pathway.suse.cz> (raw)
In-Reply-To: <20260318094555-37b1a6ce-4977-4e54-95f2-2a30bec904e1@linutronix.de>

Added John and Sebastian into Cc.

On Wed 2026-03-18 09:48:06, Thomas Weißschuh wrote:
> On Tue, Mar 17, 2026 at 12:41:23PM +0100, Thomas Weißschuh wrote:
> > Depending on the system configuration, the restricted pointer formatting
> > might call into the security subsystem which might sleep.
> > As %pK is intended to be only used from read handlers of virtual files,
> > which always run in task context, this should never happen in practice.
> > However, developers have used %pK before from atomic context without
> > realizing this restriction. While all existing user of %pK through
> > printk() have been removed, new ones might be reintroduced accidentally
> > in the future.
> > 
> > Add a might_sleep(), so that misuse of %pK from atomic context is
> > detected right away.
> > 
> > Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
> > Link: https://lore.kernel.org/lkml/20241217142032.55793-1-acarmina@redhat.com/
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> > This depends on commit 5886cc8f895b ("drm/msm/dpu: Don't use %pK through
> > printk (again)"), which was merged in v7.0-rc2.
> > ---
> >  lib/vsprintf.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index 800b8ac49f53..eb9dbb28fb9b 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -862,6 +862,9 @@ static noinline_for_stack
> >  char *restricted_pointer(char *buf, char *end, const void *ptr,
> >  			 struct printf_spec spec)
> >  {
> > +	/* Only usable from task context, The call to has_capability_noaudit() might sleep. */
> > +	might_sleep();
> > +
> 
> So might_sleep() is not actually the right thing to do here.
> Some callers use %pK under a spinlock, which fails the might_sleep() check.
> However this is fine to do, as has_capability_noaudit() also only takes a
> spinlock.

My understanding is that we want to simulate that we are going
to call a normal spin_lock() which might sleep in PREEMPT_RT.
So that we trigger the warning when %pK is used under
a raw_spin_lock.

It might likely be achieved by adding a "fake" spin_lock and might_lock().
I am not sure if there is an easier way by using just
a struct lockdep_map.

I am always a bit confused by the lockdep annotation.

> 
> >  	switch (kptr_restrict) {
> >  	case 0:
> >  		/* Handle as %p, hash and do _not_ leak addresses. */

Best Regards,
Petr

  reply	other threads:[~2026-03-18 11:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17 11:41 [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting Thomas Weißschuh
2026-03-17 14:07 ` Andy Shevchenko
2026-03-17 14:26   ` Thomas Weißschuh
2026-03-17 17:24     ` Steven Rostedt
2026-03-18  8:48 ` Thomas Weißschuh
2026-03-18 11:01   ` Petr Mladek [this message]
2026-03-18 11:03   ` Petr Mladek
2026-03-18 13:59     ` Sebastian Andrzej Siewior
2026-03-18 14:45       ` Thomas Weißschuh
2026-03-18 14:57         ` Sebastian Andrzej Siewior
2026-03-18 15:10           ` Thomas Weißschuh
2026-03-19  8:17             ` Sebastian Andrzej Siewior
2026-03-20  1:53 ` kernel test robot

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=abqF-37LT_D8WWtC@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=thomas.weissschuh@linutronix.de \
    /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.