CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

[Greg Kroah-Hartman]

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix UAF in cifs_demultiplex_thread()

There is a UAF when xfstests on cifs:

  BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160
  Read of size 4 at addr ffff88810103fc08 by task cifsd/923

  CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45
  ...
  Call Trace:
   <TASK>
   dump_stack_lvl+0x34/0x44
   print_report+0x171/0x472
   kasan_report+0xad/0x130
   kasan_check_range+0x145/0x1a0
   smb2_is_network_name_deleted+0x27/0x160
   cifs_demultiplex_thread.cold+0x172/0x5a4
   kthread+0x165/0x1a0
   ret_from_fork+0x1f/0x30
   </TASK>

  Allocated by task 923:
   kasan_save_stack+0x1e/0x40
   kasan_set_track+0x21/0x30
   __kasan_slab_alloc+0x54/0x60
   kmem_cache_alloc+0x147/0x320
   mempool_alloc+0xe1/0x260
   cifs_small_buf_get+0x24/0x60
   allocate_buffers+0xa1/0x1c0
   cifs_demultiplex_thread+0x199/0x10d0
   kthread+0x165/0x1a0
   ret_from_fork+0x1f/0x30

  Freed by task 921:
   kasan_save_stack+0x1e/0x40
   kasan_set_track+0x21/0x30
   kasan_save_free_info+0x2a/0x40
   ____kasan_slab_free+0x143/0x1b0
   kmem_cache_free+0xe3/0x4d0
   cifs_small_buf_release+0x29/0x90
   SMB2_negotiate+0x8b7/0x1c60
   smb2_negotiate+0x51/0x70
   cifs_negotiate_protocol+0xf0/0x160
   cifs_get_smb_ses+0x5fa/0x13c0
   mount_get_conns+0x7a/0x750
   cifs_mount+0x103/0xd00
   cifs_smb3_do_mount+0x1dd/0xcb0
   smb3_get_tree+0x1d5/0x300
   vfs_get_tree+0x41/0xf0
   path_mount+0x9b3/0xdd0
   __x64_sys_mount+0x190/0x1d0
   do_syscall_64+0x35/0x80
   entry_SYSCALL_64_after_hwframe+0x46/0xb0

The UAF is because:

 mount(pid: 921)               | cifsd(pid: 923)
-------------------------------|-------------------------------
                               | cifs_demultiplex_thread
SMB2_negotiate                 |
 cifs_send_recv                |
  compound_send_recv           |
   smb_send_rqst               |
    wait_for_response          |
     wait_event_state      [1] |
                               |  standard_receive3
                               |   cifs_handle_standard
                               |    handle_mid
                               |     mid->resp_buf = buf;  [2]
                               |     dequeue_mid           [3]
     KILL the process      [4] |
    resp_iov[i].iov_base = buf |
 free_rsp_buf              [5] |
                               |   is_network_name_deleted [6]
                               |   callback

1. After send request to server, wait the response until
    mid->mid_state != SUBMITTED;
2. Receive response from server, and set it to mid;
3. Set the mid state to RECEIVED;
4. Kill the process, the mid state already RECEIVED, get 0;
5. Handle and release the negotiate response;
6. UAF.

It can be easily reproduce with add some delay in [3] - [6].

Only sync call has the problem since async call's callback is
executed in cifsd process.

Add an extra state to mark the mid state to READY before wakeup the
waitter, then it can get the resp safely.

The Linux kernel CVE team has assigned CVE-2023-52572 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 2.6.16 with commit ec637e3ffb6b and fixed in 6.1.56 with commit 908b3b5e97d2
	Issue introduced in 2.6.16 with commit ec637e3ffb6b and fixed in 6.5.6 with commit 76569e3819e0
	Issue introduced in 2.6.16 with commit ec637e3ffb6b and fixed in 6.6 with commit d527f51331ca

Please see https://www.kernel.org or a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-52572
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/smb/client/cifsglob.h
	fs/smb/client/transport.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/908b3b5e97d25e879de3d1f172a255665491c2c3
	https://git.kernel.org/stable/c/76569e3819e0bb59fc19b1b8688b017e627c268a
	https://git.kernel.org/stable/c/d527f51331cace562393a8038d870b3e9916686f

Re: CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

[Robert Frohl]

[-- Attachment #1.1.1: Type: text/plain, Size: 5749 bytes --]

Hi all,

this seems to be a duplicate of CVE-2023-1192 [0], even though NVD lists 
another, wrong patch. The RH bug has more details [1].

Cheers,
Robert


[0] https://nvd.nist.gov/vuln/detail/CVE-2023-1192
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2154178#c28


On 02.03.24 23:00, Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> cifs: Fix UAF in cifs_demultiplex_thread()
> 
> There is a UAF when xfstests on cifs:
> 
>    BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160
>    Read of size 4 at addr ffff88810103fc08 by task cifsd/923
> 
>    CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45
>    ...
>    Call Trace:
>     <TASK>
>     dump_stack_lvl+0x34/0x44
>     print_report+0x171/0x472
>     kasan_report+0xad/0x130
>     kasan_check_range+0x145/0x1a0
>     smb2_is_network_name_deleted+0x27/0x160
>     cifs_demultiplex_thread.cold+0x172/0x5a4
>     kthread+0x165/0x1a0
>     ret_from_fork+0x1f/0x30
>     </TASK>
> 
>    Allocated by task 923:
>     kasan_save_stack+0x1e/0x40
>     kasan_set_track+0x21/0x30
>     __kasan_slab_alloc+0x54/0x60
>     kmem_cache_alloc+0x147/0x320
>     mempool_alloc+0xe1/0x260
>     cifs_small_buf_get+0x24/0x60
>     allocate_buffers+0xa1/0x1c0
>     cifs_demultiplex_thread+0x199/0x10d0
>     kthread+0x165/0x1a0
>     ret_from_fork+0x1f/0x30
> 
>    Freed by task 921:
>     kasan_save_stack+0x1e/0x40
>     kasan_set_track+0x21/0x30
>     kasan_save_free_info+0x2a/0x40
>     ____kasan_slab_free+0x143/0x1b0
>     kmem_cache_free+0xe3/0x4d0
>     cifs_small_buf_release+0x29/0x90
>     SMB2_negotiate+0x8b7/0x1c60
>     smb2_negotiate+0x51/0x70
>     cifs_negotiate_protocol+0xf0/0x160
>     cifs_get_smb_ses+0x5fa/0x13c0
>     mount_get_conns+0x7a/0x750
>     cifs_mount+0x103/0xd00
>     cifs_smb3_do_mount+0x1dd/0xcb0
>     smb3_get_tree+0x1d5/0x300
>     vfs_get_tree+0x41/0xf0
>     path_mount+0x9b3/0xdd0
>     __x64_sys_mount+0x190/0x1d0
>     do_syscall_64+0x35/0x80
>     entry_SYSCALL_64_after_hwframe+0x46/0xb0
> 
> The UAF is because:
> 
>   mount(pid: 921)               | cifsd(pid: 923)
> -------------------------------|-------------------------------
>                                 | cifs_demultiplex_thread
> SMB2_negotiate                 |
>   cifs_send_recv                |
>    compound_send_recv           |
>     smb_send_rqst               |
>      wait_for_response          |
>       wait_event_state      [1] |
>                                 |  standard_receive3
>                                 |   cifs_handle_standard
>                                 |    handle_mid
>                                 |     mid->resp_buf = buf;  [2]
>                                 |     dequeue_mid           [3]
>       KILL the process      [4] |
>      resp_iov[i].iov_base = buf |
>   free_rsp_buf              [5] |
>                                 |   is_network_name_deleted [6]
>                                 |   callback
> 
> 1. After send request to server, wait the response until
>      mid->mid_state != SUBMITTED;
> 2. Receive response from server, and set it to mid;
> 3. Set the mid state to RECEIVED;
> 4. Kill the process, the mid state already RECEIVED, get 0;
> 5. Handle and release the negotiate response;
> 6. UAF.
> 
> It can be easily reproduce with add some delay in [3] - [6].
> 
> Only sync call has the problem since async call's callback is
> executed in cifsd process.
> 
> Add an extra state to mark the mid state to READY before wakeup the
> waitter, then it can get the resp safely.
> 
> The Linux kernel CVE team has assigned CVE-2023-52572 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Issue introduced in 2.6.16 with commit ec637e3ffb6b and fixed in 6.1.56 with commit 908b3b5e97d2
> 	Issue introduced in 2.6.16 with commit ec637e3ffb6b and fixed in 6.5.6 with commit 76569e3819e0
> 	Issue introduced in 2.6.16 with commit ec637e3ffb6b and fixed in 6.6 with commit d527f51331ca
> 
> Please see https://www.kernel.org or a full list of currently supported
> kernel versions by the kernel community.
> 
> Unaffected versions might change over time as fixes are backported to
> older supported kernel versions.  The official CVE entry at
> 	https://cve.org/CVERecord/?id=CVE-2023-52572
> will be updated if fixes are backported, please check that for the most
> up to date information about this issue.
> 
> 
> Affected files
> ==============
> 
> The file(s) affected by this issue are:
> 	fs/smb/client/cifsglob.h
> 	fs/smb/client/transport.c
> 
> 
> Mitigation
> ==========
> 
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes.  Individual
> changes are never tested alone, but rather are part of a larger kernel
> release.  Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all.  If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> 	https://git.kernel.org/stable/c/908b3b5e97d25e879de3d1f172a255665491c2c3
> 	https://git.kernel.org/stable/c/76569e3819e0bb59fc19b1b8688b017e627c268a
> 	https://git.kernel.org/stable/c/d527f51331cace562393a8038d870b3e9916686f
> 

-- 
Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 
146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner 
Knoblich (HRB 36809, AG Nürnberg)
GPG: D29F 82AA 9FD5 9D6E 74B1  6370 089E DB3D 230A 2404

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 12035 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

[Greg Kroah-Hartman]

On Tue, Mar 05, 2024 at 11:38:49AM +0100, Robert Frohl wrote:
> Hi all,
> 
> this seems to be a duplicate of CVE-2023-1192 [0], even though NVD lists
> another, wrong patch. The RH bug has more details [1].
> 
> Cheers,
> Robert
> 
> 
> [0] https://nvd.nist.gov/vuln/detail/CVE-2023-1192
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2154178#c28

That's a mess.  Please have RH update the json entry with CVE with the
correct git commit id and then I'll be glad to revoke this.  The
information in NVD is not "real" from the point of view of the CVE
database, so I can't take information there as being correct, or not.
As you know, NVD is just an add-on for CVE entries, one of many created
by many different groups/governments.

Until it's fixed in the CVE database, this CVE should stand as it refers
to the correct fix that people need to know about, not the incorrect one
in the RH-assigned CVE.

thanks,

greg k-h

Re: CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

[Robert Frohl]

[-- Attachment #1.1.1: Type: text/plain, Size: 1499 bytes --]

Hi Redhat Security,

could you have a look and update the entry for CVE-2023-1192, if you 
agree that CVE-2023-52572 is a duplicate and the referenced patch for 
CVE-2023-1192 is incorrect ?

Thanks,
Robert

On 05.03.24 12:08, Greg Kroah-Hartman wrote:
> On Tue, Mar 05, 2024 at 11:38:49AM +0100, Robert Frohl wrote:
>> Hi all,
>>
>> this seems to be a duplicate of CVE-2023-1192 [0], even though NVD lists
>> another, wrong patch. The RH bug has more details [1].
>>
>> Cheers,
>> Robert
>>
>>
>> [0] https://nvd.nist.gov/vuln/detail/CVE-2023-1192
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2154178#c28
> 
> That's a mess.  Please have RH update the json entry with CVE with the
> correct git commit id and then I'll be glad to revoke this.  The
> information in NVD is not "real" from the point of view of the CVE
> database, so I can't take information there as being correct, or not.
> As you know, NVD is just an add-on for CVE entries, one of many created
> by many different groups/governments.
> 
> Until it's fixed in the CVE database, this CVE should stand as it refers
> to the correct fix that people need to know about, not the incorrect one
> in the RH-assigned CVE.
> 
> thanks,
> 
> greg k-h

-- 
Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 
146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner 
Knoblich (HRB 36809, AG Nürnberg)
GPG: D29F 82AA 9FD5 9D6E 74B1  6370 089E DB3D 230A 2404

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 12035 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Re: CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

[Red Hat Product Security]

[-- Attachment #1.1: Type: text/plain, Size: 2092 bytes --]

Hello!

INC2885107 (Re: CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()) has been updated.

Opened for: rfrohl@suse.de
Followers: cve@kernel.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, security@suse.de

Rohit Keshri updated your request with the following comments:

Hello Robert,
 Thank you for reaching to Red Hat Product Security.
 I have reviewed the flaws, CVE-2023-1192 has the correct patch used in the reference.
 Also, CVE-2023-52572 is a duplicate of CVE-2023-1192, which we will soon request for the same.
 I will also share some observation for CVE-2023-1192 while it us under investigation:
~~~
## TL;DR
 After CIFS transfers response data to system call, there is still a local variable points to the memory region, and if system call frees it faster than CIFS uses it, CIFS will access a free memory region when calls function such as `smb2_is_status_io_timeout()` .
 ## Detail
 When client uses CIFS, system calls about file operation will call cifs API to send samba request, and there is a CIFS kernel thread handler `cifs_demultiplex_thread()` which receives response from remote server and transfer those data to corresponding syscall request.
 In the beginning, CIFS kernel thread will allocate memory chunk to `server->smallbuf` in function `allocate_buffers()` and assign the pointer to local variable `buf` . Then cifs kernel thread will get a `struct mid_q_entry` instance from `server->ops->find_mid()` , this struct is used to transfer data between kernel thread and system call. Then cifs kernel thread calls `standard_receive3()` to receive response from server, saving data into `server->smallbuf`, assigning `server->smallbuf` to `mid_q_entry` instance `mids[0]`, and marking this `mid_q_entry` has been received response finally.
~~~
 Please let us know if there are any further queries on this please.
 Regards,
Rohit

How can I track and update my request?

To respond, reply to this email. You may also create a new email and include the request number (INC2885107) in the subject.

Thank you,
Product Security

Ref:MSG86263708

[-- Attachment #1.2: Type: text/html, Size: 2977 bytes --]

Re: Re: CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

[Greg KH]

On Tue, Mar 05, 2024 at 10:30:08AM -0800, Red Hat Product Security wrote:
> 
> Hello Robert,
>  Thank you for reaching to Red Hat Product Security.
>  I have reviewed the flaws, CVE-2023-1192 has the correct patch used in the reference.

What do you mean by "reference"?

CVE-2023-1192 points to a patch for a totally different filesystem
(ntfs3).  Will that be fixed?

And please stop responding in HTML format, the mailing lists reject this :(

thanks,

greg k-h

Re: CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

[Robert Frohl]

[-- Attachment #1.1.1: Type: text/plain, Size: 931 bytes --]

On 06.03.24 10:16, Greg KH wrote:
> On Tue, Mar 05, 2024 at 10:30:08AM -0800, Red Hat Product Security wrote:
>>
>> Hello Robert,
>>   Thank you for reaching to Red Hat Product Security.
>>   I have reviewed the flaws, CVE-2023-1192 has the correct patch used in the reference.
> 
> What do you mean by "reference"?
> 
> CVE-2023-1192 points to a patch for a totally different filesystem
> (ntfs3).  Will that be fixed?

This is also stated in the RH bugzilla, that the initial patch was wrong:
https://bugzilla.redhat.com/show_bug.cgi?id=2154178#c28

> 
> And please stop responding in HTML format, the mailing lists reject this :(
> 
> thanks,
> 
> greg k-h



-- 
Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 
146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner 
Knoblich (HRB 36809, AG Nürnberg)
GPG: D29F 82AA 9FD5 9D6E 74B1  6370 089E DB3D 230A 2404

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 12035 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

[Greg KH]

On Wed, Mar 06, 2024 at 10:23:37AM +0100, Robert Frohl wrote:
> On 06.03.24 10:16, Greg KH wrote:
> > On Tue, Mar 05, 2024 at 10:30:08AM -0800, Red Hat Product Security wrote:
> > > 
> > > Hello Robert,
> > >   Thank you for reaching to Red Hat Product Security.
> > >   I have reviewed the flaws, CVE-2023-1192 has the correct patch used in the reference.
> > 
> > What do you mean by "reference"?
> > 
> > CVE-2023-1192 points to a patch for a totally different filesystem
> > (ntfs3).  Will that be fixed?
> 
> This is also stated in the RH bugzilla, that the initial patch was wrong:
> https://bugzilla.redhat.com/show_bug.cgi?id=2154178#c28

Ok, so what will RH be doing here?

confused,

greg k-h

Re: CVE-2023-52572: cifs: Fix UAF in cifs_demultiplex_thread()

[Robert Frohl]

[-- Attachment #1.1.1: Type: text/plain, Size: 1267 bytes --]



On 06.03.24 10:45, Greg KH wrote:
> On Wed, Mar 06, 2024 at 10:23:37AM +0100, Robert Frohl wrote:
>> On 06.03.24 10:16, Greg KH wrote:
>>> On Tue, Mar 05, 2024 at 10:30:08AM -0800, Red Hat Product Security wrote:
>>>>
>>>> Hello Robert,
>>>>    Thank you for reaching to Red Hat Product Security.
>>>>    I have reviewed the flaws, CVE-2023-1192 has the correct patch used in the reference.
>>>
>>> What do you mean by "reference"?
>>>
>>> CVE-2023-1192 points to a patch for a totally different filesystem
>>> (ntfs3).  Will that be fixed?
>>
>> This is also stated in the RH bugzilla, that the initial patch was wrong:
>> https://bugzilla.redhat.com/show_bug.cgi?id=2154178#c28
> 
> Ok, so what will RH be doing here?
> 
> confused,

I hope that the additional information will help to update the published 
information.

The bug states that the initial patch was wrong, but it looks like it 
just was never updated/fixed in the published information for CVE-2023-1192.

Cheers,
Robert

-- 
Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 
146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner 
Knoblich (HRB 36809, AG Nürnberg)
GPG: D29F 82AA 9FD5 9D6E 74B1  6370 089E DB3D 230A 2404

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 12035 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]