All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Christian Brauner" <brauner@kernel.org>
Cc: linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org,
	target-devel@vger.kernel.org, bpf@vger.kernel.org,
	"Chuck Lever" <cel@kernel.org>,
	"Jeff Layton" <jlayton@kernel.org>,
	"Anna Schumaker" <anna@kernel.org>
Subject: Re: [PATCH 11/12] bpf: fs/xattr: take freeze protection in the xattr kfuncs
Date: Sat, 14 Nov 2026 11:11:36 +0000	[thread overview]
Message-ID: <sashiko-outbox-214394@kernel.org> (raw)
In-Reply-To: <20261114-work-fs-frozen_writes-v1-11-f5ae61c898b1@kernel.org>

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [High] bpf: deadlock in bpf_set_dentry_xattr() via
  bpf_lsm_inode_need_killpriv() [1]
--

commit 486e046b7935f74b8ef238345d31e9322cf39132
Author: Christian Brauner <brauner@kernel.org>

bpf: fs/xattr: take freeze protection in the xattr kfuncs

This commit takes superblock freeze protection via
sb_start_write_trylock() in bpf_set_dentry_xattr() and
bpf_remove_dentry_xattr() so that BPF LSM programs cannot modify a frozen
filesystem.

> diff --git a/fs/bpf_fs_kfuncs.c b/fs/bpf_fs_kfuncs.c
> index 35ccd98a4de64..7f61e2efa08ba 100644
> --- a/fs/bpf_fs_kfuncs.c
> +++ b/fs/bpf_fs_kfuncs.c
> @@ -295,9 +295,13 @@ __bpf_kfunc int bpf_set_dentry_xattr(struct dentry *dentry, const char *name__st
>  	if (!inode)
>  		return -EINVAL;
>  
> +	/* The hook may hold locks or freeze protection already. */
> +	if (!sb_start_write_trylock(inode->i_sb))
> +		return -EBUSY;
>  	inode_lock(inode);
>  	ret = bpf_set_dentry_xattr_locked(dentry, name__str, value_p, flags);
>  	inode_unlock(inode);
> +	sb_end_write(inode->i_sb);
>  	return ret;
>  }

[Severity: High]
This problem wasn't introduced by this patch, but can calling
bpf_set_dentry_xattr() or bpf_remove_dentry_xattr() from
bpf_lsm_inode_need_killpriv() deadlock on inode_lock(inode) [1]?

During file writes, callers of file_remove_privs_flags() ->
dentry_needs_remove_privs() -> security_inode_need_killpriv() already hold
inode_lock(inode).  Because bpf_lsm_inode_need_killpriv is missing from
d_inode_locked_hooks, the verifier routes xattr kfunc calls from that hook
to the unlocked variants instead of the _locked ones, causing the thread
to self-deadlock on inode->i_rwsem.

[1] https://sashiko.dev/#/bug/linux-8b38dfb7-78dd-457e-8674-7955f142df39

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261114-work-fs-frozen_writes-v1-0-f5ae61c898b1@kernel.org?part=11

  reply	other threads:[~2026-11-14 11:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 10:47 [PATCH 00/12] fs: take freeze protection for writes to backing files Christian Brauner
2026-11-14 10:47 ` [PATCH 01/12] fs: add kiocb_start_write_trylock() Christian Brauner
2026-11-14 10:47 ` [PATCH 02/12] zloop: take freeze protection for writes Christian Brauner
2026-11-14 10:47 ` [PATCH 03/12] nvmet: take freeze protection for writes to files Christian Brauner
2026-11-14 10:47 ` [PATCH 04/12] target: fileio: don't free the aio command under the filesystem Christian Brauner
2026-11-14 10:47 ` [PATCH 05/12] target: fileio: take freeze protection for aio writes Christian Brauner
2026-11-14 10:47 ` [PATCH 06/12] loop: take freeze protection for discard and write zeroes Christian Brauner
2026-11-14 10:47 ` [PATCH 07/12] zloop: take freeze protection when recording write pointers Christian Brauner
2026-11-14 10:47 ` [PATCH 08/12] target: fileio: take freeze protection for unmap Christian Brauner
2026-11-14 10:47 ` [PATCH 09/12] coredump: take freeze protection for the truncate Christian Brauner
2026-11-14 10:47 ` [PATCH 10/12] ovl: take freeze protection when storing the uuid Christian Brauner
2026-11-14 10:47 ` [PATCH 11/12] bpf: fs/xattr: take freeze protection in the xattr kfuncs Christian Brauner
2026-11-14 11:11   ` sashiko-bot [this message]
2026-11-14 10:47 ` [PATCH 12/12] nfsd: take freeze protection for the truncate on open Christian Brauner

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=sashiko-outbox-214394@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=anna@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=cel@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=target-devel@vger.kernel.org \
    /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.