[PATCH v3 0/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[PATCH v3 0/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[Thomas Weißschuh]

Depending on the system configuration, the restricted pointer formatting
might call into the security subsystem which takes spinlocks, which
might sleep under PREEMPT_RT. As %pK is intended to be only used from
read handlers of virtual files, which always run in task context,
this should not be a problem in practice.
However, developers have used %pK before from atomic context without
realizing this restriction.

Add a lockdep annotation to unconditionally introduce a fake spinlock in
restricted_pointer(), so lockdep can detect misuse even if the current
test system configuration would not exhibit the issue.

---
Changes in v3:
- Use in_task() over its open-coded inverse.
  - Also switch the existing check over to it.
- Link to v2: https://patch.msgid.link/20260504-restricted-pointers-final-v2-0-4934933503e5@linutronix.de

Changes in v2:
- Use custom lock_map over might_sleep()
- Also assert IRQ context
- Link to v1: https://lore.kernel.org/r/20260317-restricted-pointers-final-v1-1-b4dca0ed6483@linutronix.de

To: Andrew Morton <akpm@linux-foundation.org>
To: Petr Mladek <pmladek@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@redhat.com>
To: Will Deacon <will@kernel.org>
To: Boqun Feng <boqun@kernel.org>
To: Waiman Long <longman@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Clark Williams <clrkwllms@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-rt-devel@lists.linux.dev
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

---
Thomas Weißschuh (5):
      locking/lockdep: Add a helper to validate the locking context without a lock
      locking/lockdep: Add a guard for lock_map_acquire()
      lib/vsprintf: Validate spinlock context during restricted pointer formatting
      lib/vsprintf: Use in_task() for restricted pointer context check
      lib/vsprintf: Always check interrupt context restrictions

 include/linux/lockdep.h | 11 +++++++++++
 lib/vsprintf.c          | 13 ++++++++++++-
 2 files changed, 23 insertions(+), 1 deletion(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260107-restricted-pointers-final-cd24979fd752

Best regards,
--  
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

[PATCH v3 1/5] locking/lockdep: Add a helper to validate the locking context without a lock

[Thomas Weißschuh]

In some cases the specific codepath and its locking operations depend on
the runtime configuration of the system. lockdep will only detect lock
misuse if the system is configured in the right way by chance.

To make lockdep more reliable in these cases, introduce a helper macro
to define a lockdep map without any corresponding lock.

This differs from the related DEFINE_WAIT_OVERRIDE_MAP() as the context
of the map is checked against the current locking context.

Link: https://lore.kernel.org/lkml/20241217142032.55793-1-acarmina@redhat.com/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 include/linux/lockdep.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 621566345406..ae3e332f1518 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -315,6 +315,11 @@ extern void lock_unpin_lock(struct lockdep_map *lock, struct pin_cookie);
 		.wait_type_inner = _wait_type,		\
 		.lock_type = LD_LOCK_WAIT_OVERRIDE, }
 
+#define DEFINE_WAIT_ASSERT_MAP(_name, _wait_type)	\
+	struct lockdep_map _name = {			\
+		.name = #_name "-wait-type-assert",	\
+		.wait_type_inner = _wait_type, }
+
 #else /* !CONFIG_LOCKDEP */
 
 static inline void lockdep_init_task(struct task_struct *task)
@@ -407,6 +412,9 @@ extern int lockdep_is_held(const void *);
 #define DEFINE_WAIT_OVERRIDE_MAP(_name, _wait_type)	\
 	struct lockdep_map __maybe_unused _name = {}
 
+#define DEFINE_WAIT_ASSERT_MAP(_name, _wait_type)	\
+	struct lockdep_map __maybe_unused _name = {}
+
 #endif /* !LOCKDEP */
 
 #ifdef CONFIG_PROVE_LOCKING

-- 
2.54.0

[PATCH v3 2/5] locking/lockdep: Add a guard for lock_map_acquire()

[Thomas Weißschuh]

Make it easy to acquire a lock map based on source code structure.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 include/linux/lockdep.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index ae3e332f1518..fad8d71e0505 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -10,6 +10,7 @@
 #ifndef __LINUX_LOCKDEP_H
 #define __LINUX_LOCKDEP_H
 
+#include <linux/cleanup.h>
 #include <linux/lockdep_types.h>
 #include <linux/smp.h>
 #include <asm/percpu.h>
@@ -553,6 +554,8 @@ do {									\
 #define lock_map_release(l)			lock_release(l, _THIS_IP_)
 #define lock_map_sync(l)			lock_sync(l, 0, 0, 1, NULL, _THIS_IP_)
 
+DEFINE_GUARD(lock_map_acquire, struct lockdep_map *, lock_map_acquire(_T), lock_map_release(_T))
+
 #ifdef CONFIG_PROVE_LOCKING
 # define might_lock(lock)						\
 do {									\

-- 
2.54.0

[PATCH v3 3/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[Thomas Weißschuh]

Depending on the system configuration, the restricted pointer formatting
might call into the security subsystem which takes spinlocks, which
might sleep under PREEMPT_RT. As %pK is intended to be only used from
read handlers of virtual files, which always run in task context,
this should not be a problem 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 lockdep annotation to unconditionally introduce a fake spinlock in
restricted_pointer(), so lockdep can detect misuse even if the current
test system configuration would not exhibit the issue.

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>
---
 lib/vsprintf.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 9f359b31c8d1..021db95087fe 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -29,6 +29,7 @@
 #include <linux/hex.h>
 #include <linux/kernel.h>
 #include <linux/kallsyms.h>
+#include <linux/lockdep.h>
 #include <linux/math64.h>
 #include <linux/uaccess.h>
 #include <linux/ioport.h>
@@ -862,6 +863,14 @@ static noinline_for_stack
 char *restricted_pointer(char *buf, char *end, const void *ptr,
 			 struct printf_spec spec)
 {
+	/*
+	 * has_capability_noaudit() may use spinlocks.
+	 * Make sure %pK is only used from valid contexts.
+	 */
+	static DEFINE_WAIT_ASSERT_MAP(vsprintf_restricted_pointer_map, LD_WAIT_CONFIG);
+
+	guard(lock_map_acquire)(&vsprintf_restricted_pointer_map);
+
 	switch (kptr_restrict) {
 	case 0:
 		/* Handle as %p, hash and do _not_ leak addresses. */

-- 
2.54.0

Re: [PATCH v3 3/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[Petr Mladek]

On Wed 2026-05-20 10:40:02, Thomas Weißschuh wrote:
> Depending on the system configuration, the restricted pointer formatting
> might call into the security subsystem which takes spinlocks, which
> might sleep under PREEMPT_RT. As %pK is intended to be only used from
> read handlers of virtual files, which always run in task context,
> this should not be a problem 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 lockdep annotation to unconditionally introduce a fake spinlock in
> restricted_pointer(), so lockdep can detect misuse even if the current
> test system configuration would not exhibit the issue.
> 
> 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>
> ---
>  lib/vsprintf.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 9f359b31c8d1..021db95087fe 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -29,6 +29,7 @@
>  #include <linux/hex.h>
>  #include <linux/kernel.h>
>  #include <linux/kallsyms.h>
> +#include <linux/lockdep.h>
>  #include <linux/math64.h>
>  #include <linux/uaccess.h>
>  #include <linux/ioport.h>
> @@ -862,6 +863,14 @@ static noinline_for_stack
>  char *restricted_pointer(char *buf, char *end, const void *ptr,
>  			 struct printf_spec spec)
>  {
> +	/*
> +	 * has_capability_noaudit() may use spinlocks.
> +	 * Make sure %pK is only used from valid contexts.
> +	 */
> +	static DEFINE_WAIT_ASSERT_MAP(vsprintf_restricted_pointer_map, LD_WAIT_CONFIG);
> +
> +	guard(lock_map_acquire)(&vsprintf_restricted_pointer_map);

Here is Sashiko AI review from
https://sashiko.dev/#/patchset/20260520-restricted-pointers-final-v3-0-76bca6a6ab3f%40linutronix.de

<paste>
Will this single global lockdep map create false dependencies and
inconsistent IRQ usage splats?

Because lock_map_acquire() acquires the fake lock with trylock=0, lockdep
fully tracks it in the dependency graph. Since this is a single global
static map, it acts as a central bottleneck: every lock held by any caller
of %pK forms a forward dependency to the fake lock, and the fake lock forms
a forward dependency to any lock acquired inside %pK. This artificially
links completely independent locking contexts across the kernel, which might
generate massive false-positive circular deadlock warnings.

Furthermore, if %pK is evaluated in an IRQ context, the lock map is marked
USED_IN_HARDIRQ. If it is later evaluated in a process context with IRQs
enabled, the map is marked ENABLED_HARDIRQ. Won't lockdep immediately
trigger an inconsistent IRQ usage splat upon detecting both states?

While using trylock=1 (like lock_map_acquire_try()) might seem like a way
around this, lockdep's check_wait_context() explicitly bypasses wait-context
validation when trylock=1. This would defeat the purpose of this patch.

Is there a different mechanism to assert the wait context without fully
tracking it in the lock dependency graph?
</paste>

My opinion:

The fear of generating massive false-positive cirular locks does
not fit here. It is the opposite. This fake lock represents the
various locks which might be taken by has_capability_noaudit()
on purpose. And %pK formatting must never be used under these
locks because it might create deadlock otherwise.

The fear of inconsistent IRQ usage reports makes some sense.
It might happen and it might be confusing because %pK fomatting
must not be used in IRQ context at all. The misleading IRQ
reports should be prevented by adding the lockdep_assert(in_task)
later in this patch set.

Resume:

This patch looks good to me:

Reviewed-by: Petr Mladek <pmladek@suse.com>

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

Best Regards,
Petr

[PATCH v3 4/5] lib/vsprintf: Use in_task() for restricted pointer context check

[Thomas Weißschuh]

in_task() is a easier to read and slightly more efficient variant of
the existing tests.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/lkml/20260504130044.GU3126523@noisy.programming.kicks-ass.net/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 lib/vsprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 021db95087fe..69dbd22f0e9e 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -882,7 +882,7 @@ char *restricted_pointer(char *buf, char *end, const void *ptr,
 		 * kptr_restrict==1 cannot be used in IRQ context
 		 * because its test for CAP_SYSLOG would be meaningless.
 		 */
-		if (in_hardirq() || in_serving_softirq() || in_nmi()) {
+		if (!in_task()) {
 			if (spec.field_width == -1)
 				spec.field_width = 2 * sizeof(ptr);
 			return error_string(buf, end, "pK-error", spec);

-- 
2.54.0

[PATCH v3 5/5] lib/vsprintf: Always check interrupt context restrictions

[Thomas Weißschuh]

When kptr_restrict is set to '1' restricted pointers can not be used
in IRQ context. As kptr_restrict can change at any time at runtime,
this means that restricted pointers can not be used from IRQ context
in general.

Add some assertions to detect misuse early, independently of the
runtime configuration of the test system.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 lib/vsprintf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 69dbd22f0e9e..c48a771a3ac3 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -871,6 +871,8 @@ char *restricted_pointer(char *buf, char *end, const void *ptr,
 
 	guard(lock_map_acquire)(&vsprintf_restricted_pointer_map);
 
+	lockdep_assert(in_task());
+
 	switch (kptr_restrict) {
 	case 0:
 		/* Handle as %p, hash and do _not_ leak addresses. */

-- 
2.54.0

Re: [PATCH v3 5/5] lib/vsprintf: Always check interrupt context restrictions

[Petr Mladek]

On Wed 2026-05-20 10:40:04, Thomas Weißschuh wrote:
> When kptr_restrict is set to '1' restricted pointers can not be used
> in IRQ context. As kptr_restrict can change at any time at runtime,
> this means that restricted pointers can not be used from IRQ context
> in general.
> 
> Add some assertions to detect misuse early, independently of the
> runtime configuration of the test system.
> 
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -871,6 +871,8 @@ char *restricted_pointer(char *buf, char *end, const void *ptr,
>  
>  	guard(lock_map_acquire)(&vsprintf_restricted_pointer_map);
>  
> +	lockdep_assert(in_task());

It might make sense to do this assert before checking the fake
spinlock. The task context is more restrictive than then
the spin lock context so we might want to check it first.

It might prevent confusing reports about inconsitent IRQ
usage. This function should not be called in IRQ context
at all.

Otherwise, it looks good to me.

Best Regards,
Petr

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