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. References: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.10 https://github.com/torvalds/linux/commit/088aaf17aa79300cab14dbee2569c58cfafd7d6e https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.11 https://github.com/torvalds/linux/commit/05fd5c2c61732152a6bddc318aae62d7e436629b
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1760865]
This was fixed for Fedora with the 5.0.11 stable kernel update.
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, rc); } 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.
Mitigation: 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.