An issue was discovered in the Linux kernels CIFS client implementation. While issuing an SMB2_write a value can be used after it was intended to be freed when CIFS function tracing is enabled. While no privilege escalation is immediately obvious, Red Hat will not rule out that it may be possible.
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1750411]
Upstream Issue: https://github.com/torvalds/linux/commit/6a3eb3360667170988f8a6477f6686242061488a
This was fixed for Fedora with the 5.0.10 stable kernel updates.
So, taking a look at the context of this apparent UAF. rc = cifs_send_recv(xid, io_parms->tcon->ses, &rqst, &resp_buftype, flags, &rsp_iov); cifs_small_buf_release(req); <-- FREE HERE. rsp = (struct smb2_write_rsp *)rsp_iov.iov_base; if (rc) { trace_smb3_write_err(xid, req->PersistentFileId, io_parms->tcon->tid, io_parms->tcon->ses->Suid, io_parms->offset, io_parms->length, rc); cifs_stats_fail_inc(io_parms->tcon, SMB2_WRITE_HE); cifs_dbg(VFS, "Send error in write = %d\n", rc); } else { *nbytes = le32_to_cpu(rsp->DataLength); trace_smb3_write_done(xid, req->PersistentFileId, io_parms->tcon->tid, io_parms->tcon->ses->Suid, io_parms->offset, *nbytes); } free_rsp_buf(resp_buftype, rsp); return rc; } So, we can see that its used in trace_smb3_write_err, which is part of the cifs tracing subsystem (not enabled by default) in the kernel. In this example all it does is print out the req->PersistentFileId. If an atacker can groom it between free, this may be a null pointer deference, or an information leak.. But I don't see how it can be privesc. The fix was simply to move the free code after the use below...
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.