Re: [PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
David Windsor <[email protected]> Fri, 31 Jul 2026 11:30:39 -0400
| Newsgroups | org.kernel.vger.linux-integrity,org.kernel.vger.bpf,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-security-module,org.kernel.vger.selinux |
|---|---|
| Message-ID | <CAEXv5_iHLmzPT3Jj+qZsdt1Nk_5OD4Up3GGV0S9G7KyQshFhDA@mail.gmail.com> |
On Fri, Jul 31, 2026 at 11:17=E2=80=AFAM Paul Moore <[email protected]> w= rote: > > > Okay, it looks like there was some confusion/misunderstanding. > > My understanding of Kumar's comments was that he was referring to the > exisiting LSM related kfuncs that are located in fs/bpf_fs_kfuncs.c, > not necessarily the new kfunc you are proposing in this patchset. > Kumar is welcome to correct either one or both of us, if we read that > wrong :) > Yes, after another reading, that does appear to be the case =3D). We'll need v7 anyway to fix the ocfs-related UAF the bot found. > However, regardless of Kumar's intent, speaking as the LSM maintainer, > my stance on this is that the kfunc you are proposing must live in > security/bpf_lsm_kfuncs.c to be acceptable. > Ack, will do this in v7. The Landlock series currently up for discussion [1] is proposing placing its kfuncs in a new kernel/bpf/bpf_lsm.c. Should these maybe go there? [1] https://lore.kernel.org/bpf/20260731022047.189137-1-utilityemal77@gmail= .com/ > -- > paul-moore.com