All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "David Windsor" <dwindsor@gmail.com>
Cc: bpf@vger.kernel.org, selinux@vger.kernel.org
Subject: Re: [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
Date: Tue, 30 Jun 2026 18:54:20 +0000	[thread overview]
Message-ID: <20260630185420.96A6B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630183956.281293-3-dwindsor@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Marking `bpf_lsm_inode_init_security` as a sleepable hook allows BPF programs to trigger page faults while holding a filesystem transaction handle, leading to deadlocks.
--

commit 78be3e5567e8821124f5c2f9f979f1274f553583
Author: David Windsor <dwindsor@gmail.com>

bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling

This patch adds the bpf_init_inode_xattr kfunc to allow BPF LSM programs
to atomically set xattrs via the inode_init_security hook. The kfunc uses
lsm_get_xattr_slot and restricts usage to the bpf.* namespace.

Link: https://kernsec.org/pipermail/linux-security-module-archive/2022-October/034878.html
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bcdfd2cac55

> diff --git a/fs/bpf_fs_kfuncs.c b/fs/bpf_fs_kfuncs.c
> index 768aca2dc0f03..c4023c82f21e4 100644
> --- a/fs/bpf_fs_kfuncs.c
> +++ b/fs/bpf_fs_kfuncs.c
[ ... ]
> @@ -385,6 +463,7 @@ BTF_ID_FLAGS(func, bpf_get_file_xattr, KF_SLEEPABLE)
>  BTF_ID_FLAGS(func, bpf_set_dentry_xattr, KF_SLEEPABLE)
>  BTF_ID_FLAGS(func, bpf_remove_dentry_xattr, KF_SLEEPABLE)
>  BTF_ID_FLAGS(func, bpf_real_inode, KF_SLEEPABLE | KF_RET_NULL)
> +BTF_ID_FLAGS(func, bpf_init_inode_xattr, KF_SLEEPABLE)

[Severity: High]
Does marking this kfunc as sleepable create a risk of deadlocks?

Since the kfunc is only callable from the inode_init_security hook, marking
the hook as sleepable allows BPF programs to trigger page faults
(e.g., via bpf_copy_from_user). When a file is created (e.g., ext4_create),
the filesystem acquires a transaction handle before invoking the hook. If the
BPF program triggers a page fault, it will attempt to take mmap_read_lock.

Concurrently, another thread doing a write page fault (or mmap/mprotect)
might acquire mmap_lock and attempt to start a transaction (e.g., in
ext4_page_mkwrite), which blocks on the transaction handle held by the first
process. This creates an AB-BA deadlock between the filesystem transaction and
mmap_lock.

>  BTF_KFUNCS_END(bpf_fs_kfunc_set_ids)
>  
>  static int bpf_fs_kfuncs_filter(const struct bpf_prog *prog, u32 kfunc_id)
[ ... ]
> diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c
> index 564071a92d7d2..1c3f84a924203 100644
> --- a/kernel/bpf/bpf_lsm.c
> +++ b/kernel/bpf/bpf_lsm.c
> @@ -315,6 +315,7 @@ BTF_ID(func, bpf_lsm_inode_create)
>  BTF_ID(func, bpf_lsm_inode_free_security)
>  BTF_ID(func, bpf_lsm_inode_getattr)
>  BTF_ID(func, bpf_lsm_inode_getxattr)
> +BTF_ID(func, bpf_lsm_inode_init_security)

[Severity: High]
Is it safe to add bpf_lsm_inode_init_security to the sleepable hooks list?

As mentioned above, marking this hook as sleepable permits BPF programs to
take page faults from within a filesystem transaction, which violates
filesystem locking rules and can freeze filesystem operations.

>  BTF_ID(func, bpf_lsm_inode_mknod)
>  BTF_ID(func, bpf_lsm_inode_need_killpriv)
>  BTF_ID(func, bpf_lsm_inode_post_setxattr)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630183956.281293-1-dwindsor@gmail.com?part=2

  parent reply	other threads:[~2026-06-30 18:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30 18:39 [PATCH v4 bpf-next 0/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling David Windsor
2026-06-30 18:39 ` [PATCH v4 bpf-next 1/3] security: pass inode_init_security xattrs via struct lsm_xattrs David Windsor
2026-06-30 18:46   ` sashiko-bot
2026-06-30 18:39 ` [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling David Windsor
2026-06-30 18:46   ` David Windsor
2026-06-30 18:54   ` sashiko-bot [this message]
2026-07-01 22:54     ` David Windsor
2026-06-30 19:20   ` Paul Moore
2026-07-01  6:09     ` Alexei Starovoitov
2026-07-01 12:55       ` Paul Moore
2026-07-01 15:09         ` Paul Moore
2026-07-01 22:58         ` David Windsor
2026-07-01 23:21           ` Paul Moore
2026-06-30 18:39 ` [PATCH v4 bpf-next 3/3] selftests/bpf: add tests for bpf_init_inode_xattr kfunc David Windsor
2026-06-30 18:51   ` sashiko-bot

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=20260630185420.96A6B1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dwindsor@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=selinux@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.