public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Mickaël Salaün" <mic@digikod.net>
To: "Günther Noack" <gnoack3000@gmail.com>
Cc: 许佳凯 <xujiakai24@mails.ucas.ac.cn>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	"Günther Noack" <gnoack@google.com>,
	"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [BUG] landlock: sleeping function called from invalid context in hook_sb_delete()
Date: Thu, 20 Nov 2025 15:48:29 +0100	[thread overview]
Message-ID: <20251120.hoT5ye5thooR@digikod.net> (raw)
In-Reply-To: <20251120.c5c17c664315@gnoack.org>

Thanks for the report.

This was indeed a false positive.  The fix (previously reported by
syzkaller) is merged in -next and soon in the master branche:
https://lore.kernel.org/r/20251105212025.807549-1-mjguzik@gmail.com


On Thu, Nov 20, 2025 at 09:48:43AM +0100, Günther Noack wrote:
> Hello!
> 
> Thanks for the report!
> 
> CC-ing Mickaël, who authored that code
> 
> On Wed, Nov 12, 2025 at 10:35:17AM +0800, 许佳凯 wrote:
> > The call trace indicates that hook_sb_delete() holds s_inode_list_lock (a spinlock) while invoking operations that may eventually call iput(), which can sleep.
> > This violates the locking context expectations and triggers __might_sleep() warnings.
> > The issue seems to be related to how Landlock handles superblock cleanup during security_sb_delete().
> > 
> > 
> > I’m currently only reporting this issue to the community; the exact fix will likely need to be confirmed and implemented by the Landlock and filesystem maintainers.
> 
> This looks like a false positive to me.
> 
> There are three places where iput() is being called in hook_sb_delete,
> two of them are in places where it is *not* holding the
> s_inode_list_lock.  The one that *is* holding the s_inode_list_lock
> has the following comment:
> 
> /*
>  * At this point, we own the ihold() reference that was
>  * originally set up by get_inode_object() and the
>  * __iget() reference that we just set in this loop
>  * walk.  Therefore the following call to iput() will
>  * not sleep nor drop the inode because there is now at
>  * least two references to it.
>  */
> 
> That seems to indicate that the sleepability concern was taken into
> consideration.  iput() only sleeps if the refcount reaches zero, and
> if you can exclude that, it won't sleep.
> 
> —Günther
> 
> -- 
> 

  parent reply	other threads:[~2025-11-20 15:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-12  2:35 [BUG] landlock: sleeping function called from invalid context in hook_sb_delete() 许佳凯
2025-11-20  8:48 ` Günther Noack
2025-11-20 10:52   ` 许佳凯
2025-11-20 14:48   ` Mickaël Salaün [this message]
2025-11-21  1:01     ` 许佳凯

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=20251120.hoT5ye5thooR@digikod.net \
    --to=mic@digikod.net \
    --cc=gnoack3000@gmail.com \
    --cc=gnoack@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=xujiakai24@mails.ucas.ac.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox