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-next>] [day] [month] [year] [list]
Date: Fri, 5 Jan 2024 14:33:05 +0100
From: Salvatore Bonaccorso <carnil@...ian.org>
To: Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.com>,
	Ronnie Sahlberg <lsahlber@...hat.com>,
	Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>,
	Ben Hutchings <benh@...ian.org>
Cc: linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-kernel@...r.kernel.org
Subject: Information on use-after-free in smb2_is_status_io_timeout()?

Hi,

There is a Red Hat bugzilla report in
https://bugzilla.redhat.com/show_bug.cgi?id=2154178 about a
use-after-free in smb2_is_status_io_timeout() . While the commit noted
initially there seems not correct, Ben Hutchings raised a question on
more information in
https://bugzilla.redhat.com/show_bug.cgi?id=2154178#c24 .

(there is a CVE assigned for it, CVE-2023-1192)

To quote the initial message in RHBZ#2154178:

> A use after free flaw was found in smb2_is_status_io_timeout() in CIFS
> in the Linux Kernel. 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 leading to a denial of service.

Ben asked:

> smb2_is_status_io_timeout() is only ever called from cifs_demultiplex_thread().
> That happens after it conditionally decrypts the original receive buffer (buf) into
> one or more new buffers (bufs[...]), or otherwise sets bufs[0] = buf.  The
> decryption process looks like it can free the original buffer, resulting in the
> reported UAF.
> 
> If the error code is part of the encrypted payload, then I think the check for an
> I/O timeout should use bufs[0] like other code further down the function:
> 
> --- a/fs/smb/client/connect.c
> +++ b/fs/smb/client/connect.c
> @@ -1236,7 +1236,7 @@ cifs_demultiplex_thread(void *p)
>                 }
> 
>                 if (server->ops->is_status_io_timeout &&
> -                   server->ops->is_status_io_timeout(buf)) {
> +                   server->ops->is_status_io_timeout(bufs[0])) {
>                         num_io_timeout++;
>                         if (num_io_timeout > MAX_STATUS_IO_TIMEOUT) {
>                                 cifs_server_dbg(VFS,
> --- END ---
> 
> If the error code does not get encrypted, then the timeout check needs to be done
> further up the function.
> 
> Does anyone have a reproducer for this?

Does anyone knows more on this issue?

Regards,
Salvatore

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ