commit b0b28dc25ad57b77f6b69b40619364188e0f1354 Author: Ben Hutchings Date: Mon Mar 25 17:32:37 2019 +0000 Linux 3.16.64 commit 234a2dee1b06502face184e241e03582d7946f80 Author: Paolo Bonzini Date: Tue Jan 29 18:41:16 2019 +0100 KVM: x86: work around leak of uninitialized stack contents (CVE-2019-7222) commit 353c0956a618a07ba4bbe7ad00ff29fe70e8412a upstream. Bugzilla: 1671930 Emulation of certain instructions (VMXON, VMCLEAR, VMPTRLD, VMWRITE with memory operand, INVEPT, INVVPID) can incorrectly inject a page fault when passed an operand that points to an MMIO address. The page fault will use uninitialized kernel stack memory as the CR2 and error code. The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR exit to userspace; however, it is not an easy fix, so for now just ensure that the error code and CR2 are zero. Embargoed until Feb 7th 2019. Reported-by: Felix Wilhelm Signed-off-by: Paolo Bonzini Signed-off-by: Ben Hutchings commit 69c7b3bb99c621f44fb46c20ccef737e86e1c5c8 Author: Peter Shier Date: Thu Oct 11 11:46:46 2018 -0700 KVM: nVMX: unconditionally cancel preemption timer in free_nested (CVE-2019-7221) commit ecec76885bcfe3294685dc363fd1273df0d5d65f upstream. Bugzilla: 1671904 There are multiple code paths where an hrtimer may have been started to emulate an L1 VMX preemption timer that can result in a call to free_nested without an intervening L2 exit where the hrtimer is normally cancelled. Unconditionally cancel in free_nested to cover all cases. Embargoed until Feb 7th 2019. Signed-off-by: Peter Shier Reported-by: Jim Mattson Reviewed-by: Jim Mattson Reported-by: Felix Wilhelm Message-Id: <20181011184646.154065-1-pshier@google.com> Signed-off-by: Paolo Bonzini [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit 2aa9f75791601aab7bd02b8783aa9a8f5105f68f Author: Jann Horn Date: Sat Jan 26 01:54:33 2019 +0100 kvm: fix kvm_ioctl_create_device() reference counting (CVE-2019-6974) commit cfa39381173d5f969daf43582c95ad679189cbc9 upstream. kvm_ioctl_create_device() does the following: 1. creates a device that holds a reference to the VM object (with a borrowed reference, the VM's refcount has not been bumped yet) 2. initializes the device 3. transfers the reference to the device to the caller's file descriptor table 4. calls kvm_get_kvm() to turn the borrowed reference to the VM into a real reference The ownership transfer in step 3 must not happen before the reference to the VM becomes a proper, non-borrowed reference, which only happens in step 4. After step 3, an attacker can close the file descriptor and drop the borrowed reference, which can cause the refcount of the kvm object to drop to zero. This means that we need to grab a reference for the device before anon_inode_getfd(), otherwise the VM can disappear from under us. Fixes: 852b6d57dc7f ("kvm: add device control API") Signed-off-by: Jann Horn Signed-off-by: Paolo Bonzini Signed-off-by: Ben Hutchings commit b95f1ba83c427b38ed91e2ce39f81e5e2e04e654 Author: Dan Carpenter Date: Wed Nov 30 22:21:05 2016 +0300 KVM: use after free in kvm_ioctl_create_device() commit a0f1d21c1ccb1da66629627a74059dd7f5ac9c61 upstream. We should move the ops->destroy(dev) after the list_del(&dev->vm_node) so that we don't use "dev" after freeing it. Fixes: a28ebea2adc4 ("KVM: Protect device ops->create and list_add with kvm->lock") Signed-off-by: Dan Carpenter Reviewed-by: David Hildenbrand Signed-off-by: Radim Krčmář Signed-off-by: Ben Hutchings commit b68bf84b71970ef6eb32bd10d924d3edfa73d872 Author: Christoffer Dall Date: Tue Aug 9 19:13:01 2016 +0200 KVM: Protect device ops->create and list_add with kvm->lock commit a28ebea2adc4a2bef5989a5a181ec238f59fbcad upstream. KVM devices were manipulating list data structures without any form of synchronization, and some implementations of the create operations also suffered from a lack of synchronization. Now when we've split the xics create operation into create and init, we can hold the kvm->lock mutex while calling the create operation and when manipulating the devices list. The error path in the generic code gets slightly ugly because we have to take the mutex again and delete the device from the list, but holding the mutex during anon_inode_getfd or releasing/locking the mutex in the common non-error path seemed wrong. Signed-off-by: Christoffer Dall Reviewed-by: Paolo Bonzini Acked-by: Christian Borntraeger Signed-off-by: Radim Krčmář [bwh: Backported to 3.16: - Drop change to a failure path that doesn't exist in kvm_vgic_create() - Adjust filename, context] Signed-off-by: Ben Hutchings commit 199883f7dc5f2a89f1e393debfabcdb536b2579d Author: Christoffer Dall Date: Tue Aug 9 19:13:00 2016 +0200 KVM: PPC: Move xics_debugfs_init out of create commit 023e9fddc3616b005c3753fc1bb6526388cd7a30 upstream. As we are about to hold the kvm->lock during the create operation on KVM devices, we should move the call to xics_debugfs_init into its own function, since holding a mutex over extended amounts of time might not be a good idea. Introduce an init operation on the kvm_device_ops struct which cannot fail and call this, if configured, after the device has been created. Signed-off-by: Christoffer Dall Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Ben Hutchings commit 7c7839e0f66ae0119b2e4d3d9465adbaba1df4b4 Author: Vladis Dronov Date: Tue Jan 29 11:58:35 2019 +0100 HID: debug: fix the ring buffer implementation commit 13054abbaa4f1fd4e6f3b4b63439ec033b4c8035 upstream. Ring buffer implementation in hid_debug_event() and hid_debug_events_read() is strange allowing lost or corrupted data. After commit 717adfdaf147 ("HID: debug: check length before copy_to_user()") it is possible to enter an infinite loop in hid_debug_events_read() by providing 0 as count, this locks up a system. Fix this by rewriting the ring buffer implementation with kfifo and simplify the code. This fixes CVE-2019-3819. v2: fix an execution logic and add a comment v3: use __set_current_state() instead of set_current_state() Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187 Fixes: cd667ce24796 ("HID: use debugfs for events/reports dumping") Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()") Signed-off-by: Vladis Dronov Reviewed-by: Oleg Nesterov Signed-off-by: Benjamin Tissoires [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 9e23e2c5535a8e7c77ab3a01f92fa4ab5f15e91e Author: Rasmus Villemoes Date: Tue Nov 24 13:33:47 2015 +0100 HID: debug: improve hid_debug_event() commit 92529623d242cea4440958d7bcebdf291f4ab15e upstream. The code in hid_debug_event() causes horrible code generation. First, we do a strlen() call for every byte we copy (we're doing a store to global memory, so gcc has no way of proving that strlen(buf) doesn't change). Second, since both i, list->tail and HID_DEBUG_BUFSIZE have signed type, the modulo computation has to take into account the possibility that list->tail+i is negative, so it's not just a simple and. Fix the former by simply not doing strlen() at all (we have to load buf[i] anyway, so testing it is almost free) and the latter by changing i to unsigned. This cuts 29% (69 bytes) of the size of the function. Signed-off-by: Rasmus Villemoes Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings commit f9d19815c8092240f168275e29bd16ad321eeee8 Author: Jiri Kosina Date: Thu Apr 9 13:32:35 2015 +0200 HID: debug: fix error handling in hid_debug_events_read() commit 8fec02a73e31407e14986fca67dab48d4f777f0e upstream. In the unlikely case of hdev vanishing while hid_debug_events_read() was sleeping, we can't really break out of the case switch as with other cases, as on the way out we'll try to remove ourselves from the hdev waitqueue. Fix this by taking a shortcut exit path and avoiding cleanup that doesn't make sense in case hdev doesn't exist any more anyway. Reported-by: Jiri Slaby Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings commit 1c7dcfd106f42f09e3b7520c26e6eee70a939928 Author: Oliver Hartkopp Date: Fri Jan 4 15:55:26 2019 +0100 can: gw: ensure DLC boundaries after CAN frame modification commit 0aaa81377c5a01f686bcdb8c7a6929a7bf330c68 upstream. Muyu Yu provided a POC where user root with CAP_NET_ADMIN can create a CAN frame modification rule that makes the data length code a higher value than the available CAN frame data size. In combination with a configured checksum calculation where the result is stored relatively to the end of the data (e.g. cgw_csum_xor_rel) the tail of the skb (e.g. frag_list pointer in skb_shared_info) can be rewritten which finally can cause a system crash. Michael Kubecek suggested to drop frames that have a DLC exceeding the available space after the modification process and provided a patch that can handle CAN FD frames too. Within this patch we also limit the length for the checksum calculations to the maximum of Classic CAN data length (8). CAN frames that are dropped by these additional checks are counted with the CGW_DELETED counter which indicates misconfigurations in can-gw rules. This fixes CVE-2019-3701. Reported-by: Muyu Yu Reported-by: Marcus Meissner Suggested-by: Michal Kubecek Tested-by: Muyu Yu Tested-by: Oliver Hartkopp Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 0c4d7b52773b227211d311858f3c3b56f7c44874 Author: Willy Tarreau Date: Wed Sep 12 07:36:35 2018 +0200 net/appletalk: fix minor pointer leak to userspace in SIOCFINDIPDDPRT commit 9824dfae5741275473a23a7ed5756c7b6efacc9d upstream. Fields ->dev and ->next of struct ipddp_route may be copied to userspace on the SIOCFINDIPDDPRT ioctl. This is only accessible to CAP_NET_ADMIN though. Let's manually copy the relevant fields instead of using memcpy(). BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html Cc: Jann Horn Signed-off-by: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2d955f32f4ab31294447a01cf401cec2cef9013e Author: Hui Peng Date: Wed Dec 12 12:42:24 2018 +0100 USB: hso: Fix OOB memory access in hso_probe/hso_get_config_data commit 5146f95df782b0ac61abde36567e718692725c89 upstream. The function hso_probe reads if_num from the USB device (as an u8) and uses it without a length check to index an array, resulting in an OOB memory read in hso_probe or hso_get_config_data. Add a length check for both locations and updated hso_probe to bail on error. This issue has been assigned CVE-2018-19985. Reported-by: Hui Peng Reported-by: Mathias Payer Signed-off-by: Hui Peng Signed-off-by: Mathias Payer Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 801f9d2fb42e450a67f83c18fd5d8450ad29224f Author: Vasily Averin Date: Mon Dec 24 14:44:52 2018 +0300 sunrpc: use-after-free in svc_process_common() commit d4b09acf924b84bae77cad090a9d108e70b43643 upstream. if node have NFSv41+ mounts inside several net namespaces it can lead to use-after-free in svc_process_common() svc_process_common() /* Setup reply header */ rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr(rqstp); <<< HERE svc_process_common() can use incorrect rqstp->rq_xprt, its caller function bc_svc_process() takes it from serv->sv_bc_xprt. The problem is that serv is global structure but sv_bc_xprt is assigned per-netnamespace. According to Trond, the whole "let's set up rqstp->rq_xprt for the back channel" is nothing but a giant hack in order to work around the fact that svc_process_common() uses it to find the xpt_ops, and perform a couple of (meaningless for the back channel) tests of xpt_flags. All we really need in svc_process_common() is to be able to run rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr() Bruce J Fields points that this xpo_prep_reply_hdr() call is an awfully roundabout way just to do "svc_putnl(resv, 0);" in the tcp case. This patch does not initialiuze rqstp->rq_xprt in bc_svc_process(), now it calls svc_process_common() with rqstp->rq_xprt = NULL. To adjust reply header svc_process_common() just check rqstp->rq_prot and calls svc_tcp_prep_reply_hdr() for tcp case. To handle rqstp->rq_xprt = NULL case in functions called from svc_process_common() patch intruduces net namespace pointer svc_rqst->rq_bc_net and adjust SVC_NET() definition. Some other function was also adopted to properly handle described case. Signed-off-by: Vasily Averin Fixes: 23c20ecd4475 ("NFS: callback up - users counting cleanup") Signed-off-by: J. Bruce Fields v2: - added lost extern svc_tcp_prep_reply_hdr() - context changes in svc_process_common() - dropped trace_svc_process() changes Signed-off-by: Vasily Averin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 9ebdc41f7115c2fb37da946dd50e531d00533ca1 Author: Kees Cook Date: Tue Jul 10 16:22:22 2018 -0700 swiotlb: clean up reporting commit 7d63fb3af87aa67aa7d24466e792f9d7c57d8e79 upstream. This removes needless use of '%p', and refactors the printk calls to use pr_*() helpers instead. Signed-off-by: Kees Cook Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Christoph Hellwig [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit cc12c0099168b416f6c3eff1cd560a771f4b7c3f Author: Rohit Vaswani Date: Thu Oct 22 13:32:11 2015 -0700 mm: cma: fix incorrect type conversion for size during dma allocation commit 67a2e213e7e937c41c52ab5bc46bf3f4de469f6e upstream. This was found during userspace fuzzing test when a large size dma cma allocation is made by driver(like ion) through userspace. show_stack+0x10/0x1c dump_stack+0x74/0xc8 kasan_report_error+0x2b0/0x408 kasan_report+0x34/0x40 __asan_storeN+0x15c/0x168 memset+0x20/0x44 __dma_alloc_coherent+0x114/0x18c Signed-off-by: Rohit Vaswani Acked-by: Greg Kroah-Hartman Cc: Marek Szyprowski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: cma_alloc() does not exist so only dma_alloc_from_contiguous() needs to be changed] Signed-off-by: Ben Hutchings commit 96cbb7e99d66cef46c62dc691664d38d5ae2cd8d Author: Brian Foster Date: Tue Nov 8 12:54:14 2016 +1100 xfs: don't BUG() on mixed direct and mapped I/O commit 04197b341f23b908193308b8d63d17ff23232598 upstream. We've had reports of generic/095 causing XFS to BUG() in __xfs_get_blocks() due to the existence of delalloc blocks on a direct I/O read. generic/095 issues a mix of various types of I/O, including direct and memory mapped I/O to a single file. This is clearly not supported behavior and is known to lead to such problems. E.g., the lack of exclusion between the direct I/O and write fault paths means that a write fault can allocate delalloc blocks in a region of a file that was previously a hole after the direct read has attempted to flush/inval the file range, but before it actually reads the block mapping. In turn, the direct read discovers a delalloc extent and cannot proceed. While the appropriate solution here is to not mix direct and memory mapped I/O to the same regions of the same file, the current BUG_ON() behavior is probably overkill as it can crash the entire system. Instead, localize the failure to the I/O in question by returning an error for a direct I/O that cannot be handled safely due to delalloc blocks. Be careful to allow the case of a direct write to post-eof delalloc blocks. This can occur due to speculative preallocation and is safe as post-eof blocks are not accompanied by dirty pages in pagecache (conversely, preallocation within eof must have been zeroed, and thus dirtied, before the inode size could have been increased beyond said blocks). Finally, provide an additional warning if a direct I/O write occurs while the file is memory mapped. This may not catch all problematic scenarios, but provides a hint that some known-to-be-problematic I/O methods are in use. Signed-off-by: Brian Foster Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner [bwh: Backported to 3.16: - Assign positive error code to error variable - Adjust context] Signed-off-by: Ben Hutchings