On Fri, Feb 21, 2025 at 3:26 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
>
> On 2/21/2025 12:10 PM, Paul Moore wrote:
> > On Thu, Feb 20, 2025 at 2:30 PM Stephen Smalley
> > <stephen.smalley.work@xxxxxxxxx> wrote:
> >> commit b530104f50e8 ("lsm: lsm_context in security_dentry_init_security")
> >> did not preserve the lsm id for subsequent release calls, which results
> >> in a memory leak. Fix it by saving the lsm id in the nfs4_label and
> >> providing it on the subsequent release call.
> >>
> >> Fixes: b530104f50e8 ("lsm: lsm_context in security_dentry_init_security")
> >> Signed-off-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx>
> >> ---
> >> fs/nfs/nfs4proc.c | 7 ++++---
> >> include/linux/nfs4.h | 1 +
> >> 2 files changed, 5 insertions(+), 3 deletions(-)
> > Now that we've seen Casey's patch, I believe this patch is the better
> > solution and we should get this up to Linus during the v6.14-rcX
> > phase. I've got one minor nitpick (below), but how would you like to
> > handle this patch NFS folks? I'm guessing you would prefer to pull
> > this via the NFS tree, but if not let me know and I can pull it via
> > the LSM tree (an ACK would be appreciated).
> >
> > Acked-by: Paul Moore <paul@xxxxxxxxxxxxxx>
>
> If you like that approach better it should use a lsm_context struct for
> the nfs data rather than adding a lsm_id. Would you entertain that change?
I had considered that approach but doing so would require changing
every user of nfs4_label to use the lsm_context fields instead of the
current label/len fields (unless you are going to duplicate/alias
them). And not all of these originate from an lsm_context IIUC.
