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
>
> --
>
next prev 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