On 2/21/2025 12:42 PM, Stephen Smalley wrote:
> 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.
Sigh. I would like to disagree with you, but I can't. You can add my
Acked-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
>
