From: Salvatore Bonaccorso <carnil@debian.org>
To: Steve French <sfrench@samba.org>,
Paulo Alcantara <pc@manguebit.com>,
Ronnie Sahlberg <lsahlber@redhat.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Tom Talpey <tom@talpey.com>, Ben Hutchings <benh@debian.org>
Cc: linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
linux-kernel@vger.kernel.org
Subject: Information on use-after-free in smb2_is_status_io_timeout()?
Date: Fri, 5 Jan 2024 14:33:05 +0100 [thread overview]
Message-ID: <ZZgFEX3QNWWj_VxA@eldamar.lan> (raw)
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
next reply other threads:[~2024-01-05 13:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 13:33 Salvatore Bonaccorso [this message]
2024-01-05 14:04 ` Information on use-after-free in smb2_is_status_io_timeout()? Paulo Alcantara
2024-01-05 18:14 ` Ben Hutchings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZZgFEX3QNWWj_VxA@eldamar.lan \
--to=carnil@debian.org \
--cc=benh@debian.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsahlber@redhat.com \
--cc=pc@manguebit.com \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox