Bug 1760864 (CVE-2019-15920) - CVE-2019-15920 kernel: use-after-free information leak in SMB2_read
Summary: CVE-2019-15920 kernel: use-after-free information leak in SMB2_read
Alias: CVE-2019-15920
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1760865 1781023 1781024
Blocks: 1760866
TreeView+ depends on / blocked
Reported: 2019-10-11 14:23 UTC by Guilherme de Almeida Suckevicz
Modified: 2021-10-25 22:11 UTC (History)
42 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
An issue was discovered in the Linux kernel's implementation of the CIFS protocol. The SMB2_read function has a possible use-after-free when CIFS function tracing is enabled. While data is used after being freed, it is has not been determined how it could be used for privilege escalation.
Clone Of:
Last Closed: 2021-10-25 22:11:23 UTC

Attachments (Terms of Use)

Description Guilherme de Almeida Suckevicz 2019-10-11 14:23:59 UTC
An issue was discovered in the Linux kernels implementation of the CIFS protocol. The  SMB2_read function has a possible use-after-free when CIFS function tracing is enabled.

While no privilege escalation is immediately obvious, Red Hat will not rule out that it may be possible.


Comment 1 Guilherme de Almeida Suckevicz 2019-10-11 14:24:17 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1760865]

Comment 2 Justin M. Forbes 2019-10-11 17:31:55 UTC
This was fixed for Fedora with the 5.0.11 stable kernel update.

Comment 3 Wade Mealing 2019-12-09 04:39:56 UTC
So.. While this may be a use after free I dont think that this is as deadly as Use-after-free's due to its limited state.

	rc = cifs_send_recv(xid, ses, &rqst, &resp_buftype, flags, &rsp_iov);
	cifs_small_buf_release(req);  /* ORIGINAL BUF RELEASE  */

	rsp = (struct smb2_read_rsp *)rsp_iov.iov_base;

	if (rc) {
		if (rc != -ENODATA) {
			cifs_stats_fail_inc(io_parms->tcon, SMB2_READ_HE);
			cifs_dbg(VFS, "Send error in read = %d\n", rc);
			trace_smb3_read_err(xid, req->PersistentFileId, <- UAF HERE.
					    io_parms->tcon->tid, ses->Suid,
					    io_parms->offset, io_parms->length,
		} else
			trace_smb3_read_done(xid, req->PersistentFileId, <- UAF HERE
				    io_parms->tcon->tid, ses->Suid,
				    io_parms->offset, 0);
		free_rsp_buf(resp_buftype, rsp_iov.iov_base);
		return rc == -ENODATA ? 0 : rc;
	} else
		trace_smb3_read_done(xid, req->PersistentFileId, < - UAF HERE>
				    io_parms->tcon->tid, ses->Suid,
				    io_parms->offset, io_parms->length);

	cifs_small_buf_release(req);   /* NEW BUF RELEASE  */

So, the resource that it is attempting to manage is the 'req' structure, which if you look in the above code, the 'fix' is to free it later.  The use after free is only used in the trace_smb3_read_err codepath.  This appears to be an information leak or possibly a denial of service if the memory was able to be groomed within the race window.

These 'tracing' functions are usually only triggerable by enabling a trace in kernel mode, and you can see from the above the req

	echo N > /proc/fs/cifs/cifsFYI
	echo N > /proc/fs/cifs/traceSMB

Which are of course not writable by non privileged attackers as the standard permissions deny this.

$ ls -l
total 0
-rw-r--r--. 1 root root 0 Dec  9 14:36 cifsFYI
-rw-r--r--. 1 root root 0 Dec  9 14:36 traceSMB

So, an attacker may be able to groom memory and create an info leak or crash the system..  Although they would need to have an administrator setup to do cifs problem solving first.. It is unlikely that tracing would be a common 'production' configuration.  

With this in mind, I'd reccomend it gets fixed, but its not an urgent use-after-free with privesc abilities.   Drop some comments in the box below if I've missed something and I'd be happy to revisit this if i'm wrong.

Comment 9 Wade Mealing 2019-12-11 01:15:11 UTC

As the CIFS module will be auto-loaded when required, its use can be disabled 
by preventing the module from loading with the following instructions:

  # echo "install cifs /bin/true" >> /etc/modprobe.d/disable-cifs.conf 
The system will need to be restarted if the CIFS modules are loaded. In most circumstances, the CIFS kernel modules will be unable to be unloaded while any network interfaces are active and the protocol is in use.

If you need further assistance, see KCS article https://access.redhat.com/solutions/41278 or contact Red Hat Global Support Services.

Note You need to log in before you can comment on or make changes to this bug.