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
