Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Thomas Weißschuh]

On Wed, Mar 18, 2026 at 03:57:18PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-03-18 15:45:06 [+0100], Thomas Weißschuh wrote:
> > > might_sleep() seems reasonable if any usage under spinlock_t can be
> > > excluded.
> > 
> > Unfortunately it can't be excluded. See net/unix/af_unix.c, which uses
> > unix_state_lock(), a spinlock, around printk(%pK).
> 
> So if the security code can't use a mutex_t internally as locking then
> we can't do might_sleep() then.

Yep.

(...)

> > > The fake spinlock_t could be achieved by just something like
> > > might_lock() which would avoid any overhead of real locking.
> > 
> > might_lock() simulates and acquisition and immediate release of the lock.
> > With an alternative solution which holds the fake lock for the whole
> > execution of restricted_pointer() we could make sure that lockdep
> > can detect any incompatible locks being taken in the callees, even if
> > the actual caller of restrict_pointer() is not currently holding any
> > spinlocks which would trigger such a warning.
> > I'm happy about opinions whether this is useful.
> 
> might_lock() just grabs and releases it. You could acquire it at the top
> and drop it at the end. In order to simulate a lock+unlock behaviour
> without an actual lock.

That was my plan. My current idea uses a raw 'struct lockdep_map'
without a dummy spinlock, as the spinlock would never be used anyways.
But if the dummy spinlock would be better for some reason, let's use that.

(...)

> > > than %pK. According to commit 312b4e226951f ("vsprintf: check real
> > > user/group id for %pK") it is temporary as of 2013. There should be a
> > > check at open time instead.
> > 
> > Doing the check at open time requires some place to store the result
> > of it. The users of %pK I looked at all reused their core datastructures
> > as state in seq_file, so finding space for the result from open time
> > would require some non-trivial changes to them.
> 
> You could go for the easy solution and return early with -EACCES or so.
> That was the intention according to my understanding.

My understanding is different. The file should be readable for everybody.
But the actual contents depend on the user reading it. The clean solution
would be to check the user during open() and decide once if the pointers
should be printed raw/hashed/zeroed out.

The fact that even 13 years later there are no helpers whatsoever for
users to do the checks at open() time and later do the formatting,
probably didn't help the adoption of that scheme.


Thomas