- Jun 12, 2019
-
-
Todd Kjos authored
commit 0b050950 upstream. When allocating space in the target buffer for the security context, make sure the extra_buffers_size doesn't overflow. This can only happen if the given size is invalid, but an overflow can turn it into a valid size. Fail the transaction if an overflow is detected. Bug: 130571081 Change-Id: Ibaec652d2073491cc426a4a24004a848348316bf Signed-off-by:
Todd Kjos <tkjos@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Todd Kjos authored
commit 5cec2d2e upstream. An munmap() on a binder device causes binder_vma_close() to be called which clears the alloc->vma pointer. If direct reclaim causes binder_alloc_free_page() to be called, there is a race where alloc->vma is read into a local vma pointer and then used later after the mm->mmap_sem is acquired. This can result in calling zap_page_range() with an invalid vma which manifests as a use-after-free in zap_page_range(). The fix is to check alloc->vma after acquiring the mmap_sem (which we were acquiring anyway) and skip zap_page_range() if it has changed to NULL. Bug: 120025196 Change-Id: I2f3284d294326ec7736303374769640a1e028783 Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Cc: stable <stable@vger.kernel.org> # 4.14 Signed-off-by:
-
- May 31, 2019
-
-
Alistair Strachan authored
commit 47bb1179 upstream. When initially testing the Camera Terminal Descriptor wTerminalType field (buffer[4]), no mask is used. Later in the function, the MSB is overloaded to store the descriptor subtype, and so a mask of 0x7fff is used to check the type. If a descriptor is specially crafted to set this overloaded bit in the original wTerminalType field, the initial type check will fail (falling through, without adjusting the buffer size), but the later type checks will pass, assuming the buffer has been made suitably large, causing an overflow. Avoid this problem by checking for the MSB in the wTerminalType field. If the bit is set, assume the descriptor is bad, and abort parsing it. Originally reported here: https://groups.google.com/forum/#!topic/syzkaller/Ot1fOE6v1d8 A similar (non-compiling) patch was provided at that time. Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Alistair Strachan <astrachan@google.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
- Mar 04, 2019
-
-
Todd Kjos authored
To allow servers to verify client identity, allow a node flag to be set that causes the sender's security context to be delivered with the transaction. The BR_TRANSACTION command is extended in BR_TRANSACTION_SEC_CTX to contain a pointer to the security context string. Signed-off-by:
-
- Mar 01, 2019
-
-
Todd Kjos authored
commit 7bada55a upstream Malicious code can attempt to free buffers using the BC_FREE_BUFFER ioctl to binder. There are protections against a user freeing a buffer while in use by the kernel, however there was a window where BC_FREE_BUFFER could be used to free a recently allocated buffer that was not completely initialized. This resulted in a use-after-free detected by KASAN with a malicious test program. This window is closed by setting the buffer's allow_user_free attribute to 0 when the buffer is allocated or when the user has previously freed it instead of waiting for the caller to set it. The problem was that when the struct buffer was recycled, allow_user_free was stale and set to 1 allowing a free to go through. Bug: 116855682 Change-Id: I0b38089f6fdb1adbf7e1102747e4119c9a05b191 Signed-off-by:
Arve Hjønnevåg <arve@android.com> Cc: stable <stable@vger.kernel.org> # 4.14 Signed-off-by:
-
Matthias Schwarzott authored
[ Upstream commit 910b0797 ] Fix bug by moving the i2c_unregister_device calls after deregistration of dvb frontend. The new style i2c drivers already destroys the frontend object at i2c_unregister_device time. When the dvb frontend is unregistered afterwards it leads to this oops: [ 6058.866459] BUG: unable to handle kernel NULL pointer dereference at 00000000000001f8 [ 6058.866578] IP: dvb_frontend_stop+0x30/0xd0 [dvb_core] [ 6058.866644] PGD 0 [ 6058.866646] P4D 0 [ 6058.866726] Oops: 0000 [#1] SMP [ 6058.866768] Modules linked in: rc_pinnacle_pctv_hd(O) em28xx_rc(O) si2157(O) si2168(O) em28xx_dvb(O) em28xx(O) si2165(O) a8293(O) tda10071(O) tea5767(O) tuner(O) cx23885(O) tda18271(O) videobuf2_dvb(O) videobuf2_dma_sg(O) m88ds3103(O) tveeprom(O) cx2341x(O) v4l2_common(O) dvb_core(O) rc_core(O) videobuf2_memops(O) videobuf2_v4l2(O) videobuf2_core(O) videodev(O) media(O) bluetooth ecdh_generic ums_realtek uas rtl8192cu rtl_usb rtl8192c_common rtlwifi usb_storage snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic i2c_mux snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core kvm_intel kvm irqbypass [last unloaded: videobuf2_memops] [ 6058.867497] CPU: 2 PID: 7349 Comm: kworker/2:0 Tainted: G W O 4.13.9-gentoo #1 [ 6058.867595] Hardware name: MEDION E2050 2391/H81H3-EM2, BIOS H81EM2W08.308 08/25/2014 [ 6058.867692] Workqueue: usb_hub_wq hub_event [ 6058.867746] task: ffff88011a15e040 task.stack: ffffc90003074000 [ 6058.867825] RIP: 0010:dvb_frontend_stop+0x30/0xd0 [dvb_core] [ 6058.867896] RSP: 0018:ffffc90003077b58 EFLAGS: 00010293 [ 6058.867964] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000010040001f [ 6058.868056] RDX: ffff88011a15e040 RSI: ffffea000464e400 RDI: ffff88001cbe3028 [ 6058.868150] RBP: ffffc90003077b68 R08: ffff880119390380 R09: 000000010040001f [ 6058.868241] R10: ffffc90003077b18 R11: 000000000001e200 R12: ffff88001cbe3028 [ 6058.868330] R13: ffff88001cbe68d0 R14: ffff8800cf734000 R15: ffff8800cf734098 [ 6058.868419] FS: 0000000000000000(0000) GS:ffff88011fb00000(0000) knlGS:0000000000000000 [ 6058.868511] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6058.868578] CR2: 00000000000001f8 CR3: 00000001113c5000 CR4: 00000000001406e0 [ 6058.868662] Call Trace: [ 6058.868705] dvb_unregister_frontend+0x2a/0x80 [dvb_core] [ 6058.868774] em28xx_dvb_fini+0x132/0x220 [em28xx_dvb] [ 6058.868840] em28xx_close_extension+0x34/0x90 [em28xx] [ 6058.868902] em28xx_usb_disconnect+0x4e/0x70 [em28xx] [ 6058.868968] usb_unbind_interface+0x6d/0x260 [ 6058.869025] device_release_driver_internal+0x150/0x210 [ 6058.869094] device_release_driver+0xd/0x10 [ 6058.869150] bus_remove_device+0xe4/0x160 [ 6058.869204] device_del+0x1ce/0x2f0 [ 6058.869253] usb_disable_device+0x99/0x270 [ 6058.869306] usb_disconnect+0x8d/0x260 [ 6058.869359] hub_event+0x93d/0x1520 [ 6058.869408] ? dequeue_task_fair+0xae5/0xd20 [ 6058.869467] process_one_work+0x1d9/0x3e0 [ 6058.869522] worker_thread+0x43/0x3e0 [ 6058.869576] kthread+0x104/0x140 [ 6058.869602] ? trace_event_raw_event_workqueue_work+0x80/0x80 [ 6058.869640] ? kthread_create_on_node+0x40/0x40 [ 6058.869673] ret_from_fork+0x22/0x30 [ 6058.869698] Code: 54 49 89 fc 53 48 8b 9f 18 03 00 00 0f 1f 44 00 00 41 83 bc 24 04 05 00 00 02 74 0c 41 c7 84 24 04 05 00 00 01 00 00 00 0f ae f0 <48> 8b bb f8 01 00 00 48 85 ff 74 5c e8 df 40 f0 e0 48 8b 93 f8 [ 6058.869850] RIP: dvb_frontend_stop+0x30/0xd0 [dvb_core] RSP: ffffc90003077b58 [ 6058.869894] CR2: 00000000000001f8 [ 6058.875880] ---[ end trace 717eecf7193b3fc6 ]--- Signed-off-by:
Matthias Schwarzott <zzam@gentoo.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Theodore Ts'o authored
commit 8bc1379b upstream. Use a separate journal transaction if it turns out that we need to convert an inline file to use an data block. Otherwise we could end up failing due to not having journal credits. This addresses CVE-2018-10883. https://bugzilla.kernel.org/show_bug.cgi?id=200071 Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org [fengc@google.com: 4.4 and 4.9 backport: adjust context] Signed-off-by:
Chenbo Feng <fengc@google.com> Signed-off-by:
-
- Feb 08, 2019
-
-
Daniel Rosenberg authored
Bug: 30400942 Change-Id: I19fa5bf6e5c66b532b842180b2cf0ae04ddca337 Signed-off-by:Daniel Rosenberg <drosen@google.com>
-
- Feb 01, 2019
-
-
Theodore Ts'o authored
commit 5369a762 upstream. In theory this should have been caught earlier when the xattr list was verified, but in case it got missed, it's simple enough to add check to make sure we don't overrun the xattr buffer. This addresses CVE-2018-10879. https://bugzilla.kernel.org/show_bug.cgi?id=200001 Signed-off-by:
Andreas Dilger <adilger@dilger.ca> [bwh: Backported to 3.16: - Add inode parameter to ext4_xattr_set_entry() and update callers - Return -EIO instead of -EFSCORRUPTED on error - Adjust context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> [adjusted context for 4.9] Signed-off-by:
-
- Jan 30, 2019
-
-
Theodore Ts'o authored
commit 513f86d7 upstream. If there an inode points to a block which is also some other type of metadata block (such as a block allocation bitmap), the buffer_verified flag can be set when it was validated as that other metadata block type; however, it would make a really terrible external attribute block. The reason why we use the verified flag is to avoid constantly reverifying the block. However, it doesn't take much overhead to make sure the magic number of the xattr block is correct, and this will avoid potential crashes. This addresses CVE-2018-10879. https://bugzilla.kernel.org/show_bug.cgi?id=200001 Signed-off-by:
-
- Jan 08, 2019
-
-
Alexey Brodkin authored
Zebu boards were added in v4.9 and then renamed to "haps" in v4.10. Thus backporting commit 64234961 (ARC: configs: Remove CONFIG_INITRAMFS_SOURCE from defconfigs) we missed "zebu" defconfigs in v4.9. Note this is only applicable to "linux-4.9.y"! Spotted by KerneCI, see [1]. [1] https://storage.kernelci.org/stable/linux-4.9.y/v4.9.144/arc/zebu_hs_smp_defconfig/build.log Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Cc: Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Kevin Hilman authored
commit b7cc40c3 upstream. Change the default defconfig (used with 'make defconfig') to the ARCv2 nsim_hs_defconfig, and also switch the default Kconfig ISA selection to ARCv2. This allows several default defconfigs (e.g. make defconfig, make allnoconfig, make tinyconfig) to all work with ARCv2 by default. Note since we change default architecture from ARCompact to ARCv2 it's required to explicitly mention architecture type in ARCompact defconfigs otherwise ARCv2 will be implied and binaries will be generated for ARCv2. Cc: <stable@vger.kernel.org> # 4.4.x Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Alexey Brodkin authored
commit 40660f1f upstream. There's not much sense in doing that because if user or his build-system didn't set CROSS_COMPILE we still may very well make incorrect guess. But as it turned out setting CROSS_COMPILE is not as harmless as one may think: with recent changes that implemented automatic discovery of __host__ gcc features unconditional setup of CROSS_COMPILE leads to failures on execution of "make xxx_defconfig" with absent cross-compiler, for more info see [1]. Set CROSS_COMPILE as well gets in the way if we want only to build .dtb's (again with absent cross-compiler which is not really needed for building .dtb's), see [2]. Note, we had to change LIBGCC assignment type from ":=" to "=" so that is is resolved on its usage, otherwise if it is resolved at declaration time with missing CROSS_COMPILE we're getting this error message from host GCC: | gcc: error: unrecognized command line option -mmedium-calls | gcc: error: unrecognized command line option -mno-sdata [1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004308.html [2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004320.html Signed-off-by:
-
Alexey Brodkin authored
commit 615f6445 upstream. This check is very naive: we simply test if GCC invoked without "-mcpu=XXX" has ARC700 define set. In that case we think that GCC was built with "--with-cpu=arc700" and has libgcc built for ARC700. Otherwise if ARC700 is not defined we think that everythng was built for ARCv2. But in reality our life is much more interesting. 1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu" it may generate code for any ARC core). 2. libgcc might be built with explicitly specified "--mcpu=YYY" That's exactly what happens in case of multilibbed toolchains: - GCC is configured with default settings - All the libs built for many different CPU flavors I.e. that check gets in the way of usage of multilibbed toolchains. And even non-multilibbed toolchains are affected. OpenEmbedded also builds GCC without "--with-cpu" because each and every target component later is compiled with explicitly set "-mcpu=ZZZ". Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Alexey Brodkin authored
[ Upstream commit 74c11e30 ] GCC built for arc*-*-linux has "-mmedium-calls" implicitly enabled by default thus we don't see any problems during Linux kernel compilation. ----------------------------->8------------------------ arc-linux-gcc -mcpu=arc700 -Q --help=target | grep calls -mlong-calls [disabled] -mmedium-calls [enabled] ----------------------------->8------------------------ But if we try to use so-called Elf32 toolchain with GCC configured for arc*-*-elf* then we'd see the following failure: ----------------------------->8------------------------ init/do_mounts.o: In function 'init_rootfs': do_mounts.c:(.init.text+0x108): relocation truncated to fit: R_ARC_S21W_PCREL against symbol 'unregister_filesystem' defined in .text section in fs/filesystems.o arc-elf32-ld: final link failed: Symbol needs debug section which does not exist make: *** [vmlinux] Error 1 ----------------------------->8------------------------ That happens because neither "-mmedium-calls" nor "-mlong-calls" are enabled in Elf32 GCC: ----------------------------->8------------------------ arc-elf32-gcc -mcpu=arc700 -Q --help=target | grep calls -mlong-calls [disabled] -mmedium-calls [disabled] ----------------------------->8------------------------ Now to make it possible to use Elf32 toolchain for building Linux kernel we're explicitly add "-mmedium-calls" to CFLAGS. And since we add "-mmedium-calls" to the global CFLAGS there's no point in having per-file copies thus removing them. Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
- Jan 04, 2019
-
-
Linus Torvalds authored
commit 7a9cdebd upstream. Jann Horn points out that the vmacache_flush_all() function is not only potentially expensive, it's buggy too. It also happens to be entirely unnecessary, because the sequence number overflow case can be avoided by simply making the sequence number be 64-bit. That doesn't even grow the data structures in question, because the other adjacent fields are already 64-bit. So simplify the whole thing by just making the sequence number overflow case go away entirely, which gets rid of all the complications and makes the code faster too. Win-win. [ Oleg Nesterov points out that the VMACACHE_FULL_FLUSHES statistics also just goes away entirely with this ] Reported-by:
Jann Horn <jannh@google.com> Suggested-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Davidlohr Bueso <dave@stgolabs.net> Cc: Oleg Nesterov <oleg@redhat.com> Cc: stable@kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Linus Torvalds authored
commit eb66ae03 upstream. Jann Horn points out that our TLB flushing was subtly wrong for the mremap() case. What makes mremap() special is that we don't follow the usual "add page to list of pages to be freed, then flush tlb, and then free pages". No, mremap() obviously just _moves_ the page from one page table location to another. That matters, because mremap() thus doesn't directly control the lifetime of the moved page with a freelist: instead, the lifetime of the page is controlled by the page table locking, that serializes access to the entry. As a result, we need to flush the TLB not just before releasing the lock for the source location (to avoid any concurrent accesses to the entry), but also before we release the destination page table lock (to avoid the TLB being flushed after somebody else has already done something to that page). This also makes the whole "need_flush" logic unnecessary, since we now always end up flushing the TLB for every valid entry. Reported-and-tested-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
-
Theodore Ts'o authored
commit 8cdb5240 upstream. When expanding the extra isize space, we must never move the system.data xattr out of the inode body. For performance reasons, it doesn't make any sense, and the inline data implementation assumes that system.data xattr is never in the external xattr block. This addresses CVE-2018-10880 https://bugzilla.kernel.org/show_bug.cgi?id=200005 Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
- Nov 02, 2018
-
-
Suren Baghdasaryan authored
commit e285d5bf upstream. According to ETSI TS 102 622 specification chapter 4.4 pipe identifier is 7 bits long which allows for 128 unique pipe IDs. Because NFC_HCI_MAX_PIPES is used as the number of pipes supported and not as the max pipe ID, its value should be 128 instead of 127. nfc_hci_recv_from_llc extracts pipe ID from packet header using NFC_HCI_FRAGMENT(0x7F) mask which allows for pipe ID value of 127. Same happens when NCI_HCP_MSG_GET_PIPE() is being used. With pipes array having only 127 elements and pipe ID of 127 the OOB memory access will result. Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Allen Pais <allen.pais@oracle.com> Cc: "David S. Miller" <davem@davemloft.net> Suggested-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Suren Baghdasaryan <surenb@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Greg Hackmann authored
This patch is 4.9.y only. Kernels 4.12 and later are unaffected, since all the underlying ion_handle infrastructure has been ripped out. The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several times while operating on one of the client's ion_handles. This creates windows where userspace can call ION_IOC_FREE on the same client with the same handle, and effectively make the kernel drop its own reference. For example: - thread A: ION_IOC_ALLOC creates an ion_handle with refcount 1 - thread A: starts ION_IOC_MAP and increments the refcount to 2 - thread B: ION_IOC_FREE decrements the refcount to 1 - thread B: ION_IOC_FREE decrements the refcount to 0 and frees the handle - thread A: continues ION_IOC_MAP with a dangling ion_handle * to freed memory Fix this by holding client->lock for the duration of ION_IOC_{MAP,SHARE}, preventing the concurrent ION_IOC_FREE. Also remove ion_handle_get_by_id(), since there's literally no way to use it safely. Cc: stable@vger.kernel.org # v4.11- Signed-off-by:Greg Hackmann <ghackmann@google.com> Signed-off-by:
-
Adrian Salido authored
Commit 939c7a4f ("tracing: Introduce saved_cmdlines_size file") introduced ability to change saved cmdlines size. This resized saved command lines but missed resizing tgid mapping as well. Another issue is that when the resize happens, it removes saved command lines and reallocates new memory for it. This introduced a race condition when reading the global savecmd as this can be freed in the middle of accessing it causing a use after free access. Fix this by implementing locking. Signed-off-by:
Adrian Salido <salidoa@google.com> Bug: 36007735 Change-Id: I334791ac35f8bcbd34362ed112aa624275a46947 (cherry picked from commit 7116d306)
-
Mark Salyzyn authored
commit 7992c188 upstream. CVE-2018-9363 The buffer length is unsigned at all layers, but gets cast to int and checked in hidp_process_report and can lead to a buffer overflow. Switch len parameter to unsigned int to resolve issue. This affects 3.18 and newer kernels. Signed-off-by:
Mark Salyzyn <salyzyn@android.com> Fixes: a4b1b587 ("HID: Bluetooth: hidp: make sure input buffers are big enough") Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Kees Cook <keescook@chromium.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-bluetooth@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: security@kernel.org Cc: kernel-team@android.com Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
- Oct 04, 2018
-
-
Daniel Rosenberg authored
bug: 111641492 Change-Id: I79e9894f94880048edaf0f7cfa2d180f65cbcf3b Reported-by:
-
Daniel Rosenberg authored
The macro hides some control flow, making it easier to run into bugs. bug: 111642636 Change-Id: I37ec207c277d97c4e7f1e8381bc9ae743ad78435 Reported-by:
-
- Sep 14, 2018
-
-
Daniel Rosenberg authored
This patch is against 4.9. It does not apply to master due to a large rework of ion in 4.12 which removed the affected functions altogther. 4c23cbff ("staging: android: ion: Remove import interface") Userspace can cause the kref to handles to increment arbitrarily high. Ensure it does not overflow. Signed-off-by:
-
- Aug 08, 2018
-
-
Dmitry Shmidt authored
get_task_comm() currently checks if buf_size != TASK_COMM_LEN and fails even if sizeof(buf) > TASK_COMM_LEN. Change-Id: Icb3e9c172607534ef1db10baf5d626083db73498 Signed-off-by:Dmitry Shmidt <dimitrysh@google.com>
-
- Aug 06, 2018
-
-
Greg Kroah-Hartman authored
Changes in 4.9.118 ipv4: remove BUG_ON() from fib_compute_spec_dst net: ena: Fix use of uninitialized DMA address bits field net: fix amd-xgbe flow-control issue net: lan78xx: fix rx handling before first packet is send net: mdio-mux: bcm-iproc: fix wrong getter and setter pair NET: stmmac: align DMA stuff to largest cache line length tcp_bbr: fix bw probing to raise in-flight data for very small BDPs xen-netfront: wait xenbus state change when load module manually tcp: do not force quickack when receiving out-of-order packets tcp: add max_quickacks param to tcp_incr_quickack and tcp_enter_quickack_mode tcp: do not aggressively quick ack after ECN events tcp: refactor tcp_ecn_check_ce to remove sk type cast tcp: add one more quick ack after after ECN events pinctrl: intel: Read back TX buffer state sched/wait: Remove the lockless swait_active() check in swake_up*() bonding: avoid lockdep confusion in bond_get_stats() inet: frag: enforce memory limits earlier ipv4: frags: handle possible skb truesize change net: dsa: Do not suspend/resume closed slave_dev netlink: Fix spectre v1 gadget in netlink_create() net: stmmac: Fix WoL for PCI-based setups squashfs: more metadata hardening squashfs: more metadata hardenings can: ems_usb: Fix memory leak on ems_usb_disconnect() net: socket: fix potential spectre v1 gadget in socketcall virtio_balloon: fix another race between migration and ballooning kvm: x86: vmx: fix vpid leak crypto: padlock-aes - Fix Nano workaround data corruption drm/vc4: Reset ->{x, y}_scaling[1] when dealing with uniplanar formats scsi: sg: fix minor memory leak in error path Linux 4.9.118 Signed-off-by:Greg Kroah-Hartman <gregkh@google.com>
-
Greg Kroah-Hartman authored
-
Tony Battersby authored
commit c170e5a8 upstream. Fix a minor memory leak when there is an error opening a /dev/sg device. Fixes: cc833acb ("sg: O_EXCL and other lock handling") Cc: <stable@vger.kernel.org> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
Tony Battersby <tonyb@cybernetics.com> Reviewed-by:
Bart Van Assche <bart.vanassche@wdc.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Boris Brezillon authored
commit a6a00918 upstream. This is needed to ensure ->is_unity is correct when the plane was previously configured to output a multi-planar format with scaling enabled, and is then being reconfigured to output a uniplanar format. Fixes: fc04023f ("drm/vc4: Add support for YUV planes.") Cc: <stable@vger.kernel.org> Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180724133601.32114-1-boris.brezillon@bootlin.com Signed-off-by:
-
Herbert Xu authored
commit 46d8c4b2 upstream. This was detected by the self-test thanks to Ard's chunking patch. I finally got around to testing this out on my ancient Via box. It turns out that the workaround got the assembly wrong and we end up doing count + initial cycles of the loop instead of just count. This obviously causes corruption, either by overwriting the source that is yet to be processed, or writing over the end of the buffer. On CPUs that don't require the workaround only ECB is affected. On Nano CPUs both ECB and CBC are affected. This patch fixes it by doing the subtraction prior to the assembly. Fixes: a76c1c23 ("crypto: padlock-aes - work around Nano CPU...") Cc: <stable@vger.kernel.org> Reported-by:
Jamie Heilman <jamie@audible.transient.net> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Roman Kagan authored
commit 63aff655 upstream. VPID for the nested vcpu is allocated at vmx_create_vcpu whenever nested vmx is turned on with the module parameter. However, it's only freed if the L1 guest has executed VMXON which is not a given. As a result, on a system with nested==on every creation+deletion of an L1 vcpu without running an L2 guest results in leaking one vpid. Since the total number of vpids is limited to 64k, they can eventually get exhausted, preventing L2 from starting. Delay allocation of the L2 vpid until VMXON emulation, thus matching its freeing. Fixes: 5c614b35 Cc: stable@vger.kernel.org Signed-off-by:
Roman Kagan <rkagan@virtuozzo.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Jiang Biao authored
commit 89da619b upstream. Kernel panic when with high memory pressure, calltrace looks like, PID: 21439 TASK: ffff881be3afedd0 CPU: 16 COMMAND: "java" #0 [ffff881ec7ed7630] machine_kexec at ffffffff81059beb #1 [ffff881ec7ed7690] __crash_kexec at ffffffff81105942 #2 [ffff881ec7ed7760] crash_kexec at ffffffff81105a30 #3 [ffff881ec7ed7778] oops_end at ffffffff816902c8 #4 [ffff881ec7ed77a0] no_context at ffffffff8167ff46 #5 [ffff881ec7ed77f0] __bad_area_nosemaphore at ffffffff8167ffdc #6 [ffff881ec7ed7838] __node_set at ffffffff81680300 #7 [ffff881ec7ed7860] __do_page_fault at ffffffff8169320f #8 [ffff881ec7ed78c0] do_page_fault at ffffffff816932b5 #9 [ffff881ec7ed78f0] page_fault at ffffffff8168f4c8 [exception RIP: _raw_spin_lock_irqsave+47] RIP: ffffffff8168edef RSP: ffff881ec7ed79a8 RFLAGS: 00010046 RAX: 0000000000000246 RBX: ffffea0019740d00 RCX: ffff881ec7ed7fd8 RDX: 0000000000020000 RSI: 0000000000000016 RDI: 0000000000000008 RBP: ffff881ec7ed79a8 R8: 0000000000000246 R9: 000000000001a098 R10: ffff88107ffda000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000008 R14: ffff881ec7ed7a80 R15: ffff881be3afedd0 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 It happens in the pagefault and results in double pagefault during compacting pages when memory allocation fails. Analysed the vmcore, the page leads to second pagefault is corrupted with _mapcount=-256, but private=0. It's caused by the race between migration and ballooning, and lock missing in virtballoon_migratepage() of virtio_balloon driver. This patch fix the bug. Fixes: e2250429 ("virtio_balloon: introduce migration primitives to balloon pages") Cc: stable@vger.kernel.org Signed-off-by:
Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by:
Huang Chong <huang.chong@zte.com.cn> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Jeremy Cline authored
commit c8e8cd57 upstream. 'call' is a user-controlled value, so sanitize the array index after the bounds check to avoid speculating past the bounds of the 'nargs' array. Found with the help of Smatch: net/socket.c:2508 __do_sys_socketcall() warn: potential spectre issue 'nargs' [r] (local cap) Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Jeremy Cline <jcline@redhat.com> Signed-off-by:
-
Anton Vasilyev authored
commit 72c05f32 upstream. ems_usb_probe() allocates memory for dev->tx_msg_buffer, but there is no its deallocation in ems_usb_disconnect(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Anton Vasilyev <vasilyev@ispras.ru> Cc: <stable@vger.kernel.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Linus Torvalds authored
commit 71755ee5 upstream. The squashfs fragment reading code doesn't actually verify that the fragment is inside the fragment table. The end result _is_ verified to be inside the image when actually reading the fragment data, but before that is done, we may end up taking a page fault because the fragment table itself might not even exist. Another report from Anatoly and his endless squashfs image fuzzing. Reported-by:
Анатолий Тросиненко <anatoly.trosinenko@gmail.com> Acked-by:
: Phillip Lougher <phillip.lougher@gmail.com>,> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Linus Torvalds authored
commit d5125847 upstream. Anatoly reports another squashfs fuzzing issue, where the decompression parameters themselves are in a compressed block. This causes squashfs_read_data() to be called in order to read the decompression options before the decompression stream having been set up, making squashfs go sideways. Reported-by:
Phillip Lougher <phillip.lougher@gmail.com> Cc: stable@kernel.org Signed-off-by:
-
Jose Abreu authored
[ Upstream commit b7d0f08e ] WoL won't work in PCI-based setups because we are not saving the PCI EP state before entering suspend state and not allowing D3 wake. Fix this by using a wrapper around stmmac_{suspend/resume} which correctly sets the PCI EP state. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Joao Pinto <jpinto@synopsys.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
-
Jeremy Cline authored
[ Upstream commit bc5b6c0b ] 'protocol' is a user-controlled value, so sanitize it after the bounds check to avoid using it for speculative out-of-bounds access to arrays indexed by it. This addresses the following accesses detected with the help of smatch: * net/netlink/af_netlink.c:654 __netlink_create() warn: potential spectre issue 'nlk_cb_mutex_keys' [w] * net/netlink/af_netlink.c:654 __netlink_create() warn: potential spectre issue 'nlk_cb_mutex_key_strings' [w] * net/netlink/af_netlink.c:685 netlink_create() warn: potential spectre issue 'nl_table' [w] (local cap) Cc: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit a94c689e ] If a DSA slave network device was previously disabled, there is no need to suspend or resume it. Fixes: 24462549 ("net: dsa: allow switch drivers to implement suspend/resume hooks") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
