[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <882e6405-1d0a-ac6e-b6a1-941e60ecd222@gmail.com>
Date: Tue, 7 Feb 2023 11:22:31 +0800
From: Hangyu Hua <hbh25y@...il.com>
To: Namjae Jeon <linkinjeon@...nel.org>
Cc: sfrench@...ba.org, senozhatsky@...omium.org, tom@...pey.com,
lsahlber@...hat.com, hyc.lee@...il.com, linux-cifs@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ksmbd: fix possible memory leak in smb2_lock()
On 7/2/2023 07:44, Namjae Jeon wrote:
> 2023-02-06 11:36 GMT+09:00, Hangyu Hua <hbh25y@...il.com>:
>> argv needs to be free when setup_async_work fails or when the current
>> process is woken up.
>>
>> Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
>> Signed-off-by: Hangyu Hua <hbh25y@...il.com>
>> ---
>>
>> v2: avoid NULL pointer dereference in set_close_state_blocked_works()
>>
>> fs/ksmbd/smb2pdu.c | 5 +++++
>> fs/ksmbd/vfs_cache.c | 2 ++
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c
>> index d681f91947d9..177a24704021 100644
>> --- a/fs/ksmbd/smb2pdu.c
>> +++ b/fs/ksmbd/smb2pdu.c
>> @@ -7050,6 +7050,7 @@ int smb2_lock(struct ksmbd_work *work)
>> smb2_remove_blocked_lock,
>> argv);
>> if (rc) {
>> + kfree(argv);
>> err = -ENOMEM;
>> goto out;
>> }
>> @@ -7072,6 +7073,8 @@ int smb2_lock(struct ksmbd_work *work)
>> spin_lock(&fp->f_lock);
>> list_del(&work->fp_entry);
>> spin_unlock(&fp->f_lock);
>> + kfree(argv);
>> + work->cancel_fn = NULL;
>> rsp->hdr.Status =
>> STATUS_CANCELLED;
>> kfree(smb_lock);
>> @@ -7096,6 +7099,8 @@ int smb2_lock(struct ksmbd_work *work)
>> spin_lock(&fp->f_lock);
>> list_del(&work->fp_entry);
>> spin_unlock(&fp->f_lock);
>> + kfree(argv);
>> + work->cancel_fn = NULL;
> This doesn't seem so simple... You have to consider the racy issue
> between this change and smb2_cancel(). Also, how are you testing this
> patch?
>
Do you means a race condition between smb2_lock() and smb2_cancel()?
This look like another bug. This problem exists even if this patch does
not exist. If state becomes KSMBD_WORK_CANCELLED we shouldn't go retry.
But you are right. This patch will cause UAF in race condition. I think
setting cancel_fn to NULL before releasing argv can fix this UAF. After
this memory leak is solved we should use another patch to fix the race
condition. What do you think?
Thanks,
Hangyu
>> goto retry;
>> } else if (!rc) {
>> spin_lock(&work->conn->llist_lock);
>> diff --git a/fs/ksmbd/vfs_cache.c b/fs/ksmbd/vfs_cache.c
>> index da9163b00350..eb95c16393b7 100644
>> --- a/fs/ksmbd/vfs_cache.c
>> +++ b/fs/ksmbd/vfs_cache.c
>> @@ -372,6 +372,8 @@ static void set_close_state_blocked_works(struct
>> ksmbd_file *fp)
>> list_del(&cancel_work->fp_entry);
>> cancel_work->state = KSMBD_WORK_CLOSED;
>> cancel_work->cancel_fn(cancel_work->cancel_argv);
>> + kfree(cancel_work->cancel_argv);
>> + cancel_work->cancel_fn = NULL;
>> }
>> spin_unlock(&fp->f_lock);
>> }
>> --
>> 2.34.1
>>
>>
Powered by blists - more mailing lists