linux-kernel - Re: [PATCH v2] ksmbd: fix possible memory leak in smb2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKYAXd_qvYB1a3=4fn6VzRZGdR_ie7RfqvvtB8cYH0+GWF94Sg@mail.gmail.com>
Date:   Tue, 7 Feb 2023 13:22:58 +0900
From:   Namjae Jeon <linkinjeon@...nel.org>
To:     Hangyu Hua <hbh25y@...il.com>
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()

2023-02-07 12:22 GMT+09:00, Hangyu Hua <hbh25y@...il.com>:
> 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.
I don't know until I see your updated patch. It may be protected by lock.
> After
> this memory leak is solved we should use another patch to fix the race
> condition. What do you think?
It doesn't matter whether it's a single patch or a multi-patches, as
long as this patch doesn't cause racy issue...

Thanks.
>
> 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
>>>
>>>
>