[PATCH bpf-next 2/3] bpf: Add bpf_kern_path and bpf_path_put kfuncs

[Song Liu]

On Sat, Nov 29, 2025 at 10:46 PM Al Viro <viro at zeniv.linux.org.uk> wrote:
>
> On Sat, Nov 29, 2025 at 09:57:43PM -0800, Song Liu wrote:
>
> > > Your primitive is a walking TOCTOU bug - it's impossible to use safely.
> >
> > Good point. AFAICT, the sample TOCTOU bug applies to other LSMs that
> > care about dev_name in sb_mount, namely, aa_bind_mount() for apparmor
> > and tomoyo_mount_acl() for tomoyo.
>
> sb_mount needs to be taken out of its misery; it makes very little sense
> and it's certainly rife with TOCTOU issues.
>
> What to replace it with is an interesting question, especially considering
> how easy it is to bypass the damn thing with fsopen(), open_tree() and friends.
>
> It certainly won't be a single hook; multiplexing thing aside, if
> you look at e.g. loopback you'll see that there are two separate
> operations involved - one is cloning a tree (that's where dev_name is
> parsed in old API; the corresponding spot in the new one is open_tree()
> with OPEN_TREE_CLONE in flags) and another - attaching that tree to
> destination (move_mount(2) in the new API).

We currently have security_move_mount(), security_sb_remount(), and
security_sb_kern_mount(), so most things are somewhat covered.

> The former is "what", the latter - "where".  And in open_tree()/move_mount()
> it literally could be done by different processes - there's no problem
> with open_tree() in one process, passing the resulting descriptor to
> another process that will attach it.

For open_tree, security_file_open() can cover the "what" part of it.

>
> Any checks you do sb_mount (or in your mount_loopback) would have
> to have equivalent counterparts in those, or you get an easy way to
> bypass them.
>
> That's a very unpleasant can of worms; if you want to open it, be my
> guest, but I would seriously suggest doing that after the end of merge
> window - and going over the existing LSMs to see what they are trying to
> do in that area before starting that thread.

I very much support fixing it properly, and I don't plan to rush into a
half broken workaround. I am not very optimistic about whether
we can bring everyone to the same page, but I think it is worth a try.

> And yes, that's an example
> of the reasons why I'm very sceptical about out-of-tree modules in
> that area - with API in that state, we have no realistic way to promise
> any kind of stability, with obvious consequences for everyone we can't
> even see.

I am not sure what you mean by "with API in that state". Which API
sets are you talking about: the LSM hooks, the BPF kfuncs in
bpf_fs_kfuncs.c, or all the exported symbols that are available to in-tree
and out-of-tree LSMs? And how would you suggest we make these
APIs into a better state?

Thanks,
Song