Bugzilla – Bug 952587
VUL-0: CVE-2015-8019: kernel: Buffer overflow when copying data from skbuff to userspace
Last modified: 2017-04-13 14:22:03 UTC
Created attachment 653727 [details] CVE-2015-8019.patch from http://seclists.org/oss-sec/2015/q4/177 kb_copy_and_csum_datagram_iovec doesn't check the actual length of the iovec's buffers to which it copies data, then memcpy_toiovec can copy to an address that was not specified by userspace, but garbage lying on the kernel stack. In some cases, this address can be a valid userspace address, to which memcpy_toiovec will write the buffers. This can happen when userspace calls write followed by recvmsg. In that case, memcpy_toiovec will dump the packet contents to the buffer passed to the write call, and can for example overwrite stack contents. Patch has been submitted: http://patchwork.ozlabs.org/patch/530642/ Versions affected: stable kernels before v3.19 (3.x.y, x <= 18) that have backported commit 89c22d8c3b27 ("net: Fix skb csum races when peeking") v3.18.22 v3.14.54+ v3.12.48, v3.12.49 v3.10.90+ v3.2.72 3.16.7-ckt17, 3.16.7-ckt18 3.13.11-ckt27, 3.13.11-ckt28 More on the affected version: > This is needed for stable kernels where 89c22d8c3b27 ("net: Fix skb > csum races when peeking") has been backported but that don't have the > ioviter conversion, which is almost all the stable trees <= 3.18. > > This also fixes a kernel crash for NFS servers when the client uses > -onfsvers=3,proto=udp to mount the export. On the attached patch: > Note: this is based on 3.14.54, as 3.18 doesn't need the hunk for > net/rxrpc/ar-recvmsg.c, but all older stable kernels do. References: http://patchwork.ozlabs.org/patch/530642/ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8019 http://seclists.org/oss-sec/2015/q4/182
Doesn't seem to affect any of TD branches
On the openSUSE side, correct me if I'm wrong: openSUSE 13.1 not affected. openSUSE 13.2 not affected. openSUSE 42.1 affected.
(In reply to Andreas Stieger from comment #4) > On the openSUSE side, correct me if I'm wrong: > openSUSE 13.1 not affected. > openSUSE 13.2 not affected. > openSUSE 42.1 affected. oS-42.1 is based on 4.1.x, so it should be OK (newer than 3.19). oS-13.1 and 13.2 have no relevant patch backported.
(In reply to Takashi Iwai from comment #5) > oS-13.1 and 13.2 have no relevant patch backported. I meant, these are not affected.
Already being handled in bug 951199. Actually, the summary of this bug is incorrect. This regression can only cause skb_copy_and_csum_datagram_iovec() to write somewhere it is not supposed to if udp_recvmsg() is called with iovec larger than requested read length. However, we only have two types of syscalls: (a) recvmsg() and readv() only get struct msghdr and calculates read length from it (b) recvfrom(), recv() and read() only get buffer pointer and length and construct a one-segment iovec from those As none of the syscalls allows setting both read length and an iovec, there is no space for a buffer overflow. What can happen, however, is that if the incoming datagram is larger than supplied buffer, the syscall fails with EFAULT rather than truncating the data (and signalling this using MSG_TRUNC). For kernel code calling udp_recvmsg() via kernel_recvmsg(), it is also possible to write more data than requested read length - but not outside of the iovec passed to it.
Ok, let's make this one depend on bsc#951199 so that their status can be changed in concert.
bouncing back to @sec-team for closing. Issue was handled in bsc#951199, which is fixed now.
released