commit 3c3d05fc6e6653bdf9f7fb3fb6922b199c7ba3ec Author: Greg Kroah-Hartman Date: Wed Jun 6 16:44:39 2018 +0200 Linux 4.9.107 commit 73172520675a093c01a95e02fcc4e00b4170065a Author: Aleksey Makarov Date: Tue Oct 4 10:15:32 2016 +0300 serial: pl011: add console matching function commit 10879ae5f12e9cab3c4e8e9504c1aaa8a033bde7 upstream. This patch adds function pl011_console_match() that implements method match of struct console. It allows to match consoles against data specified in a string, for example taken from command line or compiled by ACPI SPCR table handler. This patch was merged to tty-next but then reverted because of conflict with commit 46e36683f433 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses") Now it is fixed. Signed-off-by: Aleksey Makarov Reviewed-by: Peter Hurley Acked-by: Russell King Tested-by: Christopher Covington Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 1724b70c4dfef1f38d67b9e05016f6a84086a31f Author: David S. Miller Date: Tue Aug 15 21:32:19 2017 -0700 sparc64: Don't clibber fixed registers in __multi4. commit 79db795833bf5c3e798bcd7a5aeeee3fb0505927 upstream. %g4 and %g5 are fixed registers used by the kernel for the thread pointer and the per-cpu offset. Use %o4 and %g7 instead. Diagnosis by Anthony Yznaga. Fixes: 1b4af13ff2cc ("sparc64: Add __multi3 for gcc 7.x and later.") Reported-by: Anatoly Pugachev Tested-by: Anatoly Pugachev Signed-off-by: David S. Miller Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 93960f9d447467b9e6d9a8ee1d6ca7b5b6eb25b6 Author: Hugh Dickins Date: Fri Jun 1 16:50:50 2018 -0700 mm: fix the NULL mapping case in __isolate_lru_page() commit 145e1a71e090575c74969e3daa8136d1e5b99fc8 upstream. George Boole would have noticed a slight error in 4.16 commit 69d763fc6d3a ("mm: pin address_space before dereferencing it while isolating an LRU page"). Fix it, to match both the comment above it, and the original behaviour. Although anonymous pages are not marked PageDirty at first, we have an old habit of calling SetPageDirty when a page is removed from swap cache: so there's a category of ex-swap pages that are easily migratable, but were inadvertently excluded from compaction's async migration in 4.16. Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805302014001.12558@eggly.anvils Fixes: 69d763fc6d3a ("mm: pin address_space before dereferencing it while isolating an LRU page") Signed-off-by: Hugh Dickins Acked-by: Minchan Kim Acked-by: Mel Gorman Reported-by: Ivan Kalvachev Cc: "Huang, Ying" Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f01d1b571458ebc8ef6311eef27c8a513038975b Author: Al Viro Date: Wed May 23 22:53:22 2018 -0400 fix io_destroy()/aio_complete() race commit 4faa99965e027cc057c5145ce45fa772caa04e8d upstream. If io_destroy() gets to cancelling everything that can be cancelled and gets to kiocb_cancel() calling the function driver has left in ->ki_cancel, it becomes vulnerable to a race with IO completion. At that point req is already taken off the list and aio_complete() does *NOT* spin until we (in free_ioctx_users()) releases ->ctx_lock. As the result, it proceeds to kiocb_free(), freing req just it gets passed to ->ki_cancel(). Fix is simple - remove from the list after the call of kiocb_cancel(). All instances of ->ki_cancel() already have to cope with the being called with iocb still on list - that's what happens in io_cancel(2). Cc: stable@kernel.org Fixes: 0460fef2a921 "aio: use cancellation list lazily" Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit d47c9f5c4e3ec194ec98d48ed59979e851cb1daa Author: David S. Miller Date: Thu Jun 1 09:42:46 2017 -0700 sparc64: Fix build warnings with gcc 7. commit 0fde7ad71ee371ede73b3f326e58f9e8d102feb6 upstream. arch/sparc/kernel/ds.c: In function ‘register_services’: arch/sparc/kernel/ds.c:912:3: error: ‘strcpy’: writing at least 1 byte into a region of size 0 overflows the destination Reported-by: Anatoly Pugachev Signed-off-by: David S. Miller Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit eab90eda9d707b5c0e8648e1b4c25364538d698a Author: Ondrej Zary Date: Fri Mar 9 23:22:04 2018 +0100 drm/i915: Disable LVDS on Radiant P845 commit b3fb22733ae61050f8d10a1d6a8af176c5c5db1a upstream. Radiant P845 does not have LVDS, only VGA. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468 Signed-off-by: Ondrej Zary Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180309222204.4771-1-linux@rainbow-software.org (cherry picked from commit 7f7105f99b75aca4f8c2a748ed6b82c7f8be3293) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 5ee69e647a86baf578a6571b9ba5a1869920f273 Author: Dhinakaran Pandiyan Date: Fri May 11 12:51:42 2018 -0700 drm/psr: Fix missed entry in PSR setup time table. commit bdcc02cf1bb508fc700df7662f55058f651f2621 upstream. Entry corresponding to 220 us setup time was missing. I am not aware of any specific bug this fixes, but this could potentially result in enabling PSR on a panel with a higher setup time requirement than supported by the hardware. I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a. Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()") Cc: stable@vger.kernel.org Cc: Ville Syrjälä Cc: Jose Roberto de Souza Cc: dri-devel@lists.freedesktop.org Reviewed-by: José Roberto de Souza Reviewed-by: Tarun Vyas Signed-off-by: Dhinakaran Pandiyan Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandiyan@intel.com Signed-off-by: Greg Kroah-Hartman commit 83c0c8b7ceefeb79b4906c3d332e774f465b760c Author: Parav Pandit Date: Sun May 27 14:49:16 2018 +0300 IB/core: Fix error code for invalid GID entry commit a840c93ca7582bb6c88df2345a33f979b7a67874 upstream. When a GID entry is invalid EAGAIN is returned. This is an incorrect error code, there is nothing that will make this GID entry valid again in bounded time. Some user space tools fail incorrectly if EAGAIN is returned here, and this represents a small ABI change from earlier kernels. The first patch in the Fixes list makes entries that were valid before to become invalid, allowing this code to trigger, while the second patch in the Fixes list introduced the wrong EAGAIN. Therefore revert the return result to EINVAL which matches the historical expectations of the ibv_query_gid_type() API of the libibverbs user space library. Cc: Fixes: 598ff6bae689 ("IB/core: Refactor GID modify code for RoCE") Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management") Reviewed-by: Daniel Jurgens Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 6ba7b04c063c457691e9a30d4316035a1518b287 Author: Greg Kroah-Hartman Date: Sat May 26 08:49:24 2018 +0200 hwtracing: stm: fix build error on some arches commit 806e30873f0e74d9d41b0ef761bd4d3e55c7d510 upstream. Commit b5e2ced9bf81 ("stm class: Use vmalloc for the master map") caused a build error on some arches as vmalloc.h was not explicitly included. Fix that by adding it to the list of includes. Fixes: b5e2ced9bf81 ("stm class: Use vmalloc for the master map") Reported-by: kbuild test robot Cc: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman commit 994347096a53d69ce5c9791627a9b5334d77c477 Author: Alexander Shishkin Date: Thu May 24 11:27:26 2018 +0300 stm class: Use vmalloc for the master map commit b5e2ced9bf81393034072dd4d372f6b430bc1f0a upstream. Fengguang is running into a warning from the buddy allocator: > swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null) > CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc1 #262 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 > Call Trace: ... > __kmalloc+0x14b/0x180: ____cache_alloc at mm/slab.c:3127 > stm_register_device+0xf3/0x5c0: stm_register_device at drivers/hwtracing/stm/core.c:695 ... Which is basically a result of the stm class trying to allocate ~512kB for the dummy_stm with its default parameters. There's no reason, however, for it not to be vmalloc()ed instead, which is what this patch does. Reported-by: Fengguang Wu Signed-off-by: Alexander Shishkin CC: stable@vger.kernel.org # v4.4+ Signed-off-by: Greg Kroah-Hartman commit 3875d1b83b19c75e2db2c25ef3dcd78e3d2c1d5f Author: Bart Van Assche Date: Mon May 21 11:17:29 2018 -0700 scsi: scsi_transport_srp: Fix shost to rport translation commit c9ddf73476ff4fffb7a87bd5107a0705bf2cf64b upstream. Since an SRP remote port is attached as a child to shost->shost_gendev and as the only child, the translation from the shost pointer into an rport pointer must happen by looking up the shost child that is an rport. This patch fixes the following KASAN complaint: BUG: KASAN: slab-out-of-bounds in srp_timed_out+0x57/0x110 [scsi_transport_srp] Read of size 4 at addr ffff880035d3fcc0 by task kworker/1:0H/19 CPU: 1 PID: 19 Comm: kworker/1:0H Not tainted 4.16.0-rc3-dbg+ #1 Workqueue: kblockd blk_mq_timeout_work Call Trace: dump_stack+0x85/0xc7 print_address_description+0x65/0x270 kasan_report+0x231/0x350 srp_timed_out+0x57/0x110 [scsi_transport_srp] scsi_times_out+0xc7/0x3f0 [scsi_mod] blk_mq_terminate_expired+0xc2/0x140 bt_iter+0xbc/0xd0 blk_mq_queue_tag_busy_iter+0x1c7/0x350 blk_mq_timeout_work+0x325/0x3f0 process_one_work+0x441/0xa50 worker_thread+0x76/0x6c0 kthread+0x1b2/0x1d0 ret_from_fork+0x24/0x30 Fixes: e68ca75200fe ("scsi_transport_srp: Reduce failover time") Signed-off-by: Bart Van Assche Cc: Hannes Reinecke Cc: Johannes Thumshirn Cc: Jason Gunthorpe Cc: Doug Ledford Cc: Laurence Oberman Cc: stable@vger.kernel.org Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit ef1b8fbed6c717a3fa80d878bb05dec1efd94d08 Author: Maciej W. Rozycki Date: Tue May 15 23:04:44 2018 +0100 MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests commit 28e4213dd331e944e7fca1954a946829162ed9d4 upstream. Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e. Status.FR) is not supported as the lone purpose of Config5.FRE is to emulate Status.FR=0 handling on FPU hardware that has Status.FR=1 hardwired[1][2]. Also we do not handle this case elsewhere, and assume throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot be set both at once for a task, leading to inconsistent behaviour if this does happen. Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear. This corresponds to modes allowed by `mips_set_personality_fp'. References: [1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32 Privileged Resource Architecture", Imagination Technologies, Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69 "Config5 Register Field Descriptions", p. 262 [2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64 Privileged Resource Architecture", Imagination Technologies, Document Number: MD00091, Revision 6.03, December 22, 2015, Table 9.72 "Config5 Register Field Descriptions", p. 288 Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") Signed-off-by: Maciej W. Rozycki Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: # 4.0+ Patchwork: https://patchwork.linux-mips.org/patch/19327/ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit 5826fc575b935a48c89be6a3fdc7a2f03aa76218 Author: Maciej W. Rozycki Date: Wed May 16 16:39:58 2018 +0100 MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs commit c7e814628df65f424fe197dde73bfc67e4a244d7 upstream. Use 64-bit accesses for 64-bit floating-point general registers with PTRACE_PEEKUSR, removing the truncation of their upper halves in the FR=1 mode, caused by commit bbd426f542cb ("MIPS: Simplify FP context access"), which inadvertently switched them to using 32-bit accesses. The PTRACE_POKEUSR side is fine as it's never been broken and continues using 64-bit accesses. Fixes: bbd426f542cb ("MIPS: Simplify FP context access") Signed-off-by: Maciej W. Rozycki Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: # 3.15+ Patchwork: https://patchwork.linux-mips.org/patch/19334/ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit 8978f159e27c820c86003644be9eae4acf5255ee Author: Martin Kelly Date: Mon Mar 26 14:27:52 2018 -0700 iio:kfifo_buf: check for uint overflow commit 3d13de4b027d5f6276c0f9d3a264f518747d83f2 upstream. Currently, the following causes a kernel OOPS in memcpy: echo 1073741825 > buffer/length echo 1 > buffer/enable Note that using 1073741824 instead of 1073741825 causes "write error: Cannot allocate memory" but no OOPS. This is because 1073741824 == 2^30 and 1073741825 == 2^30+1. Since kfifo rounds up to the nearest power of 2, it will actually call kmalloc with roundup_pow_of_two(length) * bytes_per_datum. Using length == 1073741825 and bytes_per_datum == 2, we get: kmalloc(roundup_pow_of_two(1073741825) * 2 or kmalloc(2147483648 * 2) or kmalloc(4294967296) or kmalloc(UINT_MAX + 1) so this overflows to 0, causing kmalloc to return ZERO_SIZE_PTR and subsequent memcpy to fail once the device is enabled. Fix this by checking for overflow prior to allocating a kfifo. With this check added, the above code returns -EINVAL when enabling the buffer, rather than causing an OOPS. Signed-off-by: Martin Kelly cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5d70bd5c98d0e655bde2aae2b5251bdd44df5e71 Author: Sarah Newman Date: Wed May 30 18:04:05 2018 -0700 net/mlx4_en: fix potential use-after-free with dma_unmap_page [ Not relevant upstream, therefore no upstream commit. ] To fix, unmap the page as soon as possible. When swiotlb is in use, calling dma_unmap_page means that the original page mapped with dma_map_page must still be valid, as swiotlb will copy data from its internal cache back to the originally requested DMA location. When GRO is enabled, before this patch all references to the original frag may be put and the page freed before dma_unmap_page in mlx4_en_free_frag is called. It is possible there is a path where the use-after-free occurs even with GRO disabled, but this has not been observed so far. The bug can be trivially detected by doing the following: * Compile the kernel with DEBUG_PAGEALLOC * Run the kernel as a Xen Dom0 * Leave GRO enabled on the interface * Run a 10 second or more test with iperf over the interface. This bug was likely introduced in commit 4cce66cdd14a ("mlx4_en: map entire pages to increase throughput"), first part of u3.6. It was incidentally fixed in commit 34db548bfb95 ("mlx4: add page recycling in receive path"), first part of v4.12. This version applies to the v4.9 series. Signed-off-by: Sarah Newman Tested-by: Sarah Newman Cc: Tariq Toukan Cc: Yishai Hadas Signed-off-by: Greg Kroah-Hartman commit e9b911a97bbd8d781d7281e913a1bc872e02f3cb Author: Nicholas Piggin Date: Sat Jun 2 21:09:08 2018 +1000 powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit commit a048a07d7f4535baa4cbad6bc024f175317ab938 upstream. On some CPUs we can prevent a vulnerability related to store-to-load forwarding by preventing store forwarding between privilege domains, by inserting a barrier in kernel entry and exit paths. This is known to be the case on at least Power7, Power8 and Power9 powerpc CPUs. Barriers must be inserted generally before the first load after moving to a higher privilege, and after the last store before moving to a lower privilege, HV and PR privilege transitions must be protected. Barriers are added as patch sections, with all kernel/hypervisor entry points patched, and the exit points to lower privilge levels patched similarly to the RFI flush patching. Firmware advertisement is not implemented yet, so CPU flush types are hard coded. Thanks to Michal Suchánek for bug fixes and review. Signed-off-by: Nicholas Piggin Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Neuling Signed-off-by: Michal Suchánek Signed-off-by: Michael Ellerman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2149936d12894357af9f50cb3effb99f3b41b4ce Author: Michael Ellerman Date: Sat Jun 2 21:09:07 2018 +1000 powerpc/64s: Fix section mismatch warnings from setup_rfi_flush() commit 501a78cbc17c329fabf8e9750a1e9ab810c88a0e upstream. The recent LPM changes to setup_rfi_flush() are causing some section mismatch warnings because we removed the __init annotation on setup_rfi_flush(): The function setup_rfi_flush() references the function __init ppc64_bolted_size(). the function __init memblock_alloc_base(). The references are actually in init_fallback_flush(), but that is inlined into setup_rfi_flush(). These references are safe because: - only pseries calls setup_rfi_flush() at runtime - pseries always passes L1D_FLUSH_FALLBACK at boot - so the fallback flush area will always be allocated - so the check in init_fallback_flush() will always return early: /* Only allocate the fallback flush area once (at boot time). */ if (l1d_flush_fallback_area) return; - and therefore we won't actually call the freed init routines. We should rework the code to make it safer by default rather than relying on the above, but for now as a quick-fix just add a __ref annotation to squash the warning. Fixes: abf110f3e1ce ("powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 9aa638676be49e9372f0b570cd729145ea122061 Author: Mauricio Faria de Oliveira Date: Sat Jun 2 21:09:06 2018 +1000 powerpc/pseries: Restore default security feature flags on setup commit 6232774f1599028a15418179d17f7df47ede770a upstream. After migration the security feature flags might have changed (e.g., destination system with unpatched firmware), but some flags are not set/clear again in init_cpu_char_feature_flags() because it assumes the security flags to be the defaults. Additionally, if the H_GET_CPU_CHARACTERISTICS hypercall fails then init_cpu_char_feature_flags() does not run again, which potentially might leave the system in an insecure or sub-optimal configuration. So, just restore the security feature flags to the defaults assumed by init_cpu_char_feature_flags() so it can set/clear them correctly, and to ensure safe settings are in place in case the hypercall fail. Fixes: f636c14790ea ("powerpc/pseries: Set or clear security feature flags") Depends-on: 19887d6a28e2 ("powerpc: Move default security feature flags") Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4ec7e5e89fd4cdc0e2695a2e0d7541916193f6e2 Author: Mauricio Faria de Oliveira Date: Sat Jun 2 21:09:05 2018 +1000 powerpc: Move default security feature flags commit e7347a86830f38dc3e40c8f7e28c04412b12a2e7 upstream. This moves the definition of the default security feature flags (i.e., enabled by default) closer to the security feature flags. This can be used to restore current flags to the default flags. Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 9e337dcf2edc095971751bf55293f8a92d5e55e3 Author: Mauricio Faria de Oliveira Date: Sat Jun 2 21:09:04 2018 +1000 powerpc/pseries: Fix clearing of security feature flags commit 0f9bdfe3c77091e8704d2e510eb7c2c2c6cde524 upstream. The H_CPU_BEHAV_* flags should be checked for in the 'behaviour' field of 'struct h_cpu_char_result' -- 'character' is for H_CPU_CHAR_* flags. Found by playing around with QEMU's implementation of the hypercall: H_CPU_CHAR=0xf000000000000000 H_CPU_BEHAV=0x0000000000000000 This clears H_CPU_BEHAV_FAVOUR_SECURITY and H_CPU_BEHAV_L1D_FLUSH_PR so pseries_setup_rfi_flush() disables 'rfi_flush'; and it also clears H_CPU_CHAR_L1D_THREAD_PRIV flag. So there is no RFI flush mitigation at all for cpu_show_meltdown() to report; but currently it does: Original kernel: # cat /sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: RFI Flush Patched kernel: # cat /sys/devices/system/cpu/vulnerabilities/meltdown Not affected H_CPU_CHAR=0x0000000000000000 H_CPU_BEHAV=0xf000000000000000 This sets H_CPU_BEHAV_BNDS_CHK_SPEC_BAR so cpu_show_spectre_v1() should report vulnerable; but currently it doesn't: Original kernel: # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Not affected Patched kernel: # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Vulnerable Brown-paper-bag-by: Michael Ellerman Fixes: f636c14790ea ("powerpc/pseries: Set or clear security feature flags") Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 1dc0f1f17539c3931c9e3613ce59aa37d3747c94 Author: Michael Ellerman Date: Sat Jun 2 21:09:03 2018 +1000 powerpc/64s: Wire up cpu_show_spectre_v2() commit d6fbe1c55c55c6937cbea3531af7da84ab7473c3 upstream. Add a definition for cpu_show_spectre_v2() to override the generic version. This has several permuations, though in practice some may not occur we cater for any combination. The most verbose is: Mitigation: Indirect branch serialisation (kernel only), Indirect branch cache disabled, ori31 speculation barrier enabled We don't treat the ori31 speculation barrier as a mitigation on its own, because it has to be *used* by code in order to be a mitigation and we don't know if userspace is doing that. So if that's all we see we say: Vulnerable, ori31 speculation barrier enabled Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ed50e032f7de992352d57e3dd9dd2f8a6a235e95 Author: Michael Ellerman Date: Sat Jun 2 21:09:02 2018 +1000 powerpc/64s: Wire up cpu_show_spectre_v1() commit 56986016cb8cd9050e601831fe89f332b4e3c46e upstream. Add a definition for cpu_show_spectre_v1() to override the generic version. Currently this just prints "Not affected" or "Vulnerable" based on the firmware flag. Although the kernel does have array_index_nospec() in a few places, we haven't yet audited all the powerpc code to see where it's necessary, so for now we don't list that as a mitigation. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 76e0b304b38764497044fb064deafd79a0d92c14 Author: Michael Ellerman Date: Sat Jun 2 21:09:01 2018 +1000 powerpc/pseries: Use the security flags in pseries_setup_rfi_flush() commit 2e4a16161fcd324b1f9bf6cb6856529f7eaf0689 upstream. Now that we have the security flags we can simplify the code in pseries_setup_rfi_flush() because the security flags have pessimistic defaults. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit fe1a517821084cc8c80fc4d0bd9da86323868769 Author: Michael Ellerman Date: Sat Jun 2 21:09:00 2018 +1000 powerpc/powernv: Use the security flags in pnv_setup_rfi_flush() commit 37c0bdd00d3ae83369ab60a6712c28e11e6458d5 upstream. Now that we have the security flags we can significantly simplify the code in pnv_setup_rfi_flush(), because we can use the flags instead of checking device tree properties and because the security flags have pessimistic defaults. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit a8f6001c701d0619abe1d266f958b131ea767890 Author: Michael Ellerman Date: Sat Jun 2 21:08:59 2018 +1000 powerpc/64s: Enhance the information in cpu_show_meltdown() commit ff348355e9c72493947be337bb4fae4fc1a41eba upstream. Now that we have the security feature flags we can make the information displayed in the "meltdown" file more informative. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 6f81254e77e238d04215dfa0d952f6af5819cc1d Author: Michael Ellerman Date: Sat Jun 2 21:08:58 2018 +1000 powerpc/64s: Move cpu_show_meltdown() commit 8ad33041563a10b34988800c682ada14b2612533 upstream. This landed in setup_64.c for no good reason other than we had nowhere else to put it. Now that we have a security-related file, that is a better place for it so move it. [mpe: Add extern for rfi_flush to fix bisection break] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit bdcfeadf97700af96107929a92ceaf04beb323f9 Author: Michael Ellerman Date: Sat Jun 2 21:08:57 2018 +1000 powerpc/powernv: Set or clear security feature flags commit 77addf6e95c8689e478d607176b399a6242a777e upstream. Now that we have feature flags for security related things, set or clear them based on what we see in the device tree provided by firmware. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 7be06caae78e49812522422e3d3ed9c8b788999f Author: Michael Ellerman Date: Sat Jun 2 21:08:56 2018 +1000 powerpc/pseries: Set or clear security feature flags commit f636c14790ead6cc22cf62279b1f8d7e11a67116 upstream. Now that we have feature flags for security related things, set or clear them based on what we receive from the hypercall. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 62dfddfaf19a36dea650c192e7f5571e76bf1c0e Author: Michael Ellerman Date: Sat Jun 2 21:08:55 2018 +1000 powerpc: Add security feature flags for Spectre/Meltdown commit 9a868f634349e62922c226834aa23e3d1329ae7f upstream. This commit adds security feature flags to reflect the settings we receive from firmware regarding Spectre/Meltdown mitigations. The feature names reflect the names we are given by firmware on bare metal machines. See the hostboot source for details. Arguably these could be firmware features, but that then requires them to be read early in boot so they're available prior to asm feature patching, but we don't actually want to use them for patching. We may also want to dynamically update them in future, which would be incompatible with the way firmware features work (at the moment at least). So for now just make them separate flags. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 45bc42bf044ab5c305d8edc935ab8bf42e5806bf Author: Michael Ellerman Date: Sat Jun 2 21:08:54 2018 +1000 powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags commit c4bc36628d7f8b664657d8bd6ad1c44c177880b7 upstream. Add some additional values which have been defined for the H_GET_CPU_CHARACTERISTICS hypercall. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 82bfffedbda91ffdf7cebc210185fac3f6a2096b Author: Michael Ellerman Date: Sat Jun 2 21:08:53 2018 +1000 powerpc/rfi-flush: Call setup_rfi_flush() after LPM migration commit 921bc6cf807ceb2ab8005319cf39f33494d6b100 upstream. We might have migrated to a machine that uses a different flush type, or doesn't need flushing at all. Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 2b2f103b689bb1f092ccbc5f03ce5ec77d319319 Author: Mauricio Faria de Oliveira Date: Sat Jun 2 21:08:52 2018 +1000 powerpc/rfi-flush: Differentiate enabled and patched flush types commit 0063d61ccfc011f379a31acaeba6de7c926fed2c upstream. Currently the rfi-flush messages print 'Using flush' for all enabled_flush_types, but that is not necessarily true -- as now the fallback flush is always enabled on pseries, but the fixup function overwrites its nop/branch slot with other flush types, if available. So, replace the 'Using flush' messages with ' flush is available'. Also, print the patched flush types in the fixup function, so users can know what is (not) being used (e.g., the slower, fallback flush, or no flush type at all if flush is disabled via the debugfs switch). Suggested-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 135b2c17cf252f539103fb4781133058be83a710 Author: Michael Ellerman Date: Sat Jun 2 21:08:51 2018 +1000 powerpc/rfi-flush: Always enable fallback flush on pseries commit 84749a58b6e382f109abf1e734bc4dd43c2c25bb upstream. This ensures the fallback flush area is always allocated on pseries, so in case a LPAR is migrated from a patched to an unpatched system, it is possible to enable the fallback flush in the target system. Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 5e9ea71d85bc33f869b4d8c9b5142ac30baa9118 Author: Michael Ellerman Date: Sat Jun 2 21:08:50 2018 +1000 powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again commit abf110f3e1cea40f5ea15e85f5d67c39c14568a7 upstream. For PowerVM migration we want to be able to call setup_rfi_flush() again after we've migrated the partition. To support that we need to check that we're not trying to allocate the fallback flush area after memblock has gone away (i.e., boot-time only). Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit a1bbe5eb6c01fa47ab7fb2688183fd11ebc3e2bb Author: Michael Ellerman Date: Sat Jun 2 21:08:49 2018 +1000 powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code commit 1e2a9fc7496955faacbbed49461d611b704a7505 upstream. rfi_flush_enable() includes a check to see if we're already enabled (or disabled), and in that case does nothing. But that means calling setup_rfi_flush() a 2nd time doesn't actually work, which is a bit confusing. Move that check into the debugfs code, where it really belongs. Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 98df74652bfa95856f3ad8cf7b220b01e4a39aaf Author: Michael Ellerman Date: Sat Jun 2 21:08:48 2018 +1000 powerpc/powernv: Support firmware disable of RFI flush commit eb0a2d2620ae431c543963c8c7f08f597366fc60 upstream. Some versions of firmware will have a setting that can be configured to disable the RFI flush, add support for it. Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush settings") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 51cbb3b34c8972e0096ed8d5cd4abfa586567852 Author: Michael Ellerman Date: Sat Jun 2 21:08:47 2018 +1000 powerpc/pseries: Support firmware disable of RFI flush commit 582605a429e20ae68fd0b041b2e840af296edd08 upstream. Some versions of firmware will have a setting that can be configured to disable the RFI flush, add support for it. Fixes: 8989d56878a7 ("powerpc/pseries: Query hypervisor for RFI flush settings") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 70e51fd51f00744dc9b7f017019da5d65bc32997 Author: Michael Ellerman Date: Sat Jun 2 21:08:46 2018 +1000 powerpc/rfi-flush: Move out of HARDLOCKUP_DETECTOR #ifdef The backport of the RFI flush support, done by me, has a minor bug in that the code is inside an #ifdef CONFIG_HARDLOCKUP_DETECTOR, which is incorrect. This doesn't matter with common configs because we enable HARDLOCKUP_DETECTOR, but with future patches it will break the build. So fix it. Fixes: c3b82ebee6e0 ("powerpc/64s: Add support for RFI flush of L1-D cache") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit b1d57084b6a2572c5f648c83dbd31100e73a4653 Author: Mark Rutland Date: Tue May 16 15:18:05 2017 +0100 arm64/cpufeature: don't use mutex in bringup path commit 63a1e1c95e60e798fa09ab3c536fb555aa5bbf2b upstream. Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which must take the jump_label mutex. We call cpus_set_cap() in the secondary bringup path, from the idle thread where interrupts are disabled. Taking a mutex in this path "is a NONO" regardless of whether it's contended, and something we must avoid. We didn't spot this until recently, as ___might_sleep() won't warn for this case until all CPUs have been brought up. This patch avoids taking the mutex in the secondary bringup path. The poking of static keys is deferred until enable_cpu_capabilities(), which runs in a suitable context on the boot CPU. To account for the static keys being set later, cpus_have_const_cap() is updated to use another static key to check whether the const cap keys have been initialised, falling back to the caps bitmap until this is the case. This means that users of cpus_have_const_cap() gain should only gain a single additional NOP in the fast path once the const caps are initialised, but should always see the current cap value. The hyp code should never dereference the caps array, since the caps are initialized before we run the module initcall to initialise hyp. A check is added to the hyp init code to document this requirement. This change will sidestep a number of issues when the upcoming hotplug locking rework is merged. Signed-off-by: Mark Rutland Reviewed-by: Marc Zyniger Reviewed-by: Suzuki Poulose Acked-by: Will Deacon Cc: Christoffer Dall Cc: Peter Zijlstra Cc: Sebastian Sewior Cc: Thomas Gleixner Signed-off-by: Catalin Marinas [4.9: this avoids an IPI before GICv3 is up, preventing a boot time crash] Signed-off-by: Mark Rutland [v4.9 backport] Signed-off-by: Greg Kroah-Hartman commit fe64d7d6ab83b03c933d9f76643b810857774306 Author: Suzuki K Poulose Date: Tue Nov 8 13:56:20 2016 +0000 arm64: Add hypervisor safe helper for checking constant capabilities commit a4023f682739439b434165b54af7cb3676a4766e upstream. The hypervisor may not have full access to the kernel data structures and hence cannot safely use cpus_have_cap() helper for checking the system capability. Add a safe helper for hypervisors to check a constant system capability, which *doesn't* fall back to checking the bitmap maintained by the kernel. With this, make the cpus_have_cap() only check the bitmask and force constant cap checks to use the new API for quicker checks. Cc: Robert Ritcher Cc: Tirumalesh Chalamarla Signed-off-by: Suzuki K Poulose Reviewed-by: Will Deacon Reviewed-by: Marc Zyngier Signed-off-by: Catalin Marinas [4.9: restore cpus_have_const_cap() to previously-backported code] Signed-off-by: Mark Rutland [v4.9 backport] Signed-off-by: Greg Kroah-Hartman commit e1928457073c996ffc681be2b6f9576706fbcf8d Author: Potomski, MichalX Date: Thu Feb 23 09:05:30 2017 +0000 scsi: ufs: Factor out ufshcd_read_desc_param commit a4b0e8a4e92b1baa860e744847fbdb84a50a5071 upstream. Since in UFS 2.1 specification some of the descriptor lengths differs from 2.0 specification and some devices, which are reporting spec version 2.0 have different descriptor lengths we can not rely on hardcoded values taken from 2.0 specification. This patch introduces reading these lengths per each device from descriptor headers at probe time to ensure their correctness. Signed-off-by: Michal' Potomski Reviewed-by: Subhash Jadavani Signed-off-by: Martin K. Petersen [Wei Li: Slight tweaks to get the cherry-pick to apply,resolved collisions] Signed-off-by: Li Wei Signed-off-by: Greg Kroah-Hartman commit be4d66d6b6f2cdfec92f1bd2fd44edd633097afd Author: Tomas Winkler Date: Thu Jan 5 10:45:12 2017 +0200 scsi: ufs: refactor device descriptor reading commit 93fdd5ac64bbe80dac6416f048405362d7ef0945 upstream. Pull device descriptor reading out of ufs quirk so it can be used also for other purposes. Revamp the fixup setup: 1. Rename ufs_device_info to ufs_dev_desc as very similar name ufs_dev_info is already in use. 2. Make the handlers static as they are not used out of the ufshdc.c file. [mkp: applied by hand] Signed-off-by: Tomas Winkler Reviewed-by: Subhash Jadavani Signed-off-by: Martin K. Petersen Signed-off-by: Li Wei Signed-off-by: Greg Kroah-Hartman commit b0a12b452a082ee2b29dfe9ce3818b3690c6f596 Author: Subhash Jadavani Date: Wed Nov 23 16:31:41 2016 -0800 scsi: ufs: fix failure to read the string descriptor commit bde44bb665d049468b6a1a2fa7d666434de4f83f upstream. While reading variable size descriptors (like string descriptor), some UFS devices may report the "LENGTH" (field in "Transaction Specific fields" of Query Response UPIU) same as what was requested in Query Request UPIU instead of reporting the actual size of the variable size descriptor. Although it's safe to ignore the "LENGTH" field for variable size descriptors as we can always derive the length of the descriptor from the descriptor header fields. Hence this change impose the length match check only for fixed size descriptors (for which we always request the correct size as part of Query Request UPIU). Reviewed-by: Venkat Gopalakrishnan Signed-off-by: Subhash Jadavani Signed-off-by: Martin K. Petersen [Wei Li: Slight tweaks to get the cherry-pick to apply,resolved collisions.] Signed-off-by: Li Wei Signed-off-by: Greg Kroah-Hartman commit 7966e76f6a2484573e00e1661a37c974854f4367 Author: Eric Dumazet Date: Sun Dec 10 17:55:03 2017 -0800 tcp: avoid integer overflows in tcp_rcv_space_adjust() commit 607065bad9931e72207b0cac365d7d4abc06bd99 upstream. When using large tcp_rmem[2] values (I did tests with 500 MB), I noticed overflows while computing rcvwin. Lets fix this before the following patch. Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh Acked-by: Wei Wang Acked-by: Neal Cardwell Signed-off-by: David S. Miller [Backport: sysctl_tcp_rmem is not Namespace-ify'd in older kernels] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit c43b4ff972a986c85bdd8dc1aa05fe23b29ef99c Author: Juergen Gross Date: Wed May 30 13:09:58 2018 +0200 x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen Upstream commit: def9331a12977770cc6132d79f8e6565871e8e38 ("x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen") When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window has enlarged a little bit by using setup_clear_cpu_cap() instead of the hypervisor's set_cpu_features callback. It seems this larger window now makes it rather easy to hit the problem. The proper solution is to never set the bit in case of Xen. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Acked-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit bb70de1f993b5a7fffe9d42c68907b60ef5319a6 Author: Juergen Gross Date: Wed May 30 13:09:57 2018 +0200 xen: set cpu capabilities from xen_start_kernel() Upstream commit: 0808e80cb760de2733c0527d2090ed2205a1eef8 ("xen: set cpu capabilities from xen_start_kernel()") There is no need to set the same capabilities for each cpu individually. This can easily be done for all cpus when starting the kernel. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 474928b8f0a6ba49872ef2769610b80638820aad Author: Juergen Gross Date: Wed May 30 13:09:56 2018 +0200 x86/amd: revert commit 944e0fc51a89c9827b9 Revert commit 944e0fc51a89c9827b98813d65dc083274777c7f ("x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen") as it is lacking a prerequisite patch and is making things worse. Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 219270d70a8783ad067e7c471eefdf27cc93b1d1 Author: Colin Ian King Date: Tue Oct 31 10:27:47 2017 +0000 platform/chrome: cros_ec_lpc: remove redundant pointer request commit d3b56c566d4ba8cae688baf3cca94425d57ea783 upstream. Pointer request is being assigned but never used, so remove it. Cleans up the clang warning: drivers/platform/chrome/cros_ec_lpc.c:68:2: warning: Value stored to 'request' is never read Signed-off-by: Colin Ian King Signed-off-by: Benson Leung Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit a38249d6dcfb6554f0765f9529d49f96454d9a1e Author: Colin Ian King Date: Thu Oct 19 14:33:52 2017 +0200 ASoC: Intel: sst: remove redundant variable dma_dev_name commit 271ef65b5882425d500e969e875c98e47a6b0c86 upstream. The pointer dma_dev_name is assigned but never read, it is redundant and can therefore be removed. Cleans up clang warning: sound/soc/intel/common/sst-firmware.c:288:3: warning: Value stored to 'dma_dev_name' is never read Signed-off-by: Colin Ian King Acked-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit fd9c9fff2fee867a42d83eca65eb5767d1837193 Author: Matthias Kaehlcke Date: Thu Feb 8 16:57:12 2018 -0800 rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c commit fb239c1209bb0f0b4830cc72507cc2f2d63fadbd upstream. In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal is assigned to itself in an if ... else statement, apparently only to document that the branch condition is handled and that a previously read value should be returned unmodified. The self-assignment causes clang to raise the following warning: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13: error: explicitly assigning value of variable of type 'u32' (aka 'unsigned int') to itself [-Werror,-Wself-assign] writeVal = writeVal; Delete the branch with the self-assignment. Signed-off-by: Matthias Kaehlcke Acked-by: Larry Finger Reviewed-by: Guenter Roeck Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ecfed29cc1951c5affac0cb5be9f50cfa1036700 Author: Colin Ian King Date: Fri Sep 15 00:05:16 2017 +0100 dma-buf: remove redundant initialization of sg_table commit 531beb067c6185aceabfdee0965234c6a8fd133b upstream. sg_table is being initialized and is never read before it is updated again later on, hence making the initialization redundant. Remove the initialization. Detected by clang scan-build: "warning: Value stored to 'sg_table' during its initialization is never read" Signed-off-by: Colin Ian King Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20170914230516.6056-1-colin.king@canonical.com Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit fa4724c51a898f64263ed06b4f76976b48debedf Author: Eric Biggers Date: Mon May 14 20:09:24 2018 -0700 cfg80211: further limit wiphy names to 64 bytes commit 814596495dd2b9d4aab92d8f89cf19060d25d2ea upstream. wiphy names were recently limited to 128 bytes by commit a7cfebcb7594 ("cfg80211: limit wiphy names to 128 bytes"). As it turns out though, this isn't sufficient because dev_vprintk_emit() needs the syslog header string "SUBSYSTEM=ieee80211\0DEVICE=+ieee80211:$devname" to fit into 128 bytes. This triggered the "device/subsystem name too long" WARN when the device name was >= 90 bytes. As before, this was reproduced by syzbot by sending an HWSIM_CMD_NEW_RADIO command to the MAC80211_HWSIM generic netlink family. Fix it by further limiting wiphy names to 64 bytes. Reported-by: syzbot+e64565577af34b3768dc@syzkaller.appspotmail.com Fixes: a7cfebcb7594 ("cfg80211: limit wiphy names to 128 bytes") Signed-off-by: Eric Biggers Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit c738c806495e62e0eef6a2ee2eddb32b83751eb8 Author: Sachin Grover Date: Fri May 25 14:01:39 2018 +0530 selinux: KASAN: slab-out-of-bounds in xattr_getsecurity commit efe3de79e0b52ca281ef6691480c8c68c82a4657 upstream. Call trace: [] dump_backtrace+0x0/0x428 [] show_stack+0x28/0x38 [] dump_stack+0xd4/0x124 [] print_address_description+0x68/0x258 [] kasan_report.part.2+0x228/0x2f0 [] kasan_report+0x5c/0x70 [] check_memory_region+0x12c/0x1c0 [] memcpy+0x34/0x68 [] xattr_getsecurity+0xe0/0x160 [] vfs_getxattr+0xc8/0x120 [] getxattr+0x100/0x2c8 [] SyS_fgetxattr+0x64/0xa0 [] el0_svc_naked+0x24/0x28 If user get root access and calls security.selinux setxattr() with an embedded NUL on a file and then if some process performs a getxattr() on that file with a length greater than the actual length of the string, it would result in a panic. To fix this, add the actual length of the string to the security context instead of the length passed by the userspace process. Signed-off-by: Sachin Grover Cc: stable@vger.kernel.org Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit dfc80dcea2b101828cb07654dcc797166d3e1292 Author: Steven Rostedt (VMware) Date: Sun May 27 20:54:44 2018 -0400 tracing: Fix crash when freeing instances with event triggers commit 86b389ff22bd6ad8fd3cb98e41cd271886c6d023 upstream. If a instance has an event trigger enabled when it is freed, it could cause an access of free memory. Here's the case that crashes: # cd /sys/kernel/tracing # mkdir instances/foo # echo snapshot > instances/foo/events/initcall/initcall_start/trigger # rmdir instances/foo Would produce: general protection fault: 0000 [#1] PREEMPT SMP PTI Modules linked in: tun bridge ... CPU: 5 PID: 6203 Comm: rmdir Tainted: G W 4.17.0-rc4-test+ #933 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:clear_event_triggers+0x3b/0x70 RSP: 0018:ffffc90003783de0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b2b RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800c7130ba0 RBP: ffffc90003783e00 R08: ffff8801131993f8 R09: 0000000100230016 R10: ffffc90003783d80 R11: 0000000000000000 R12: ffff8800c7130ba0 R13: ffff8800c7130bd8 R14: ffff8800cc093768 R15: 00000000ffffff9c FS: 00007f6f4aa86700(0000) GS:ffff88011eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6f4a5aed60 CR3: 00000000cd552001 CR4: 00000000001606e0 Call Trace: event_trace_del_tracer+0x2a/0xc5 instance_rmdir+0x15c/0x200 tracefs_syscall_rmdir+0x52/0x90 vfs_rmdir+0xdb/0x160 do_rmdir+0x16d/0x1c0 __x64_sys_rmdir+0x17/0x20 do_syscall_64+0x55/0x1a0 entry_SYSCALL_64_after_hwframe+0x49/0xbe This was due to the call the clears out the triggers when an instance is being deleted not removing the trigger from the link list. Cc: stable@vger.kernel.org Fixes: 85f2b08268c01 ("tracing: Add basic event trigger framework") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 87efba9b5b558bd87c2a3bdd9f0193519fa7c3a7 Author: Benjamin Tissoires Date: Tue May 22 17:19:57 2018 -0700 Input: elan_i2c_smbus - fix corrupted stack commit 40f7090bb1b4ec327ea1e1402ff5783af5b35195 upstream. New ICs (like the one on the Lenovo T480s) answer to ETP_SMBUS_IAP_VERSION_CMD 4 bytes instead of 3. This corrupts the stack as i2c_smbus_read_block_data() uses the values returned by the i2c device to know how many data it need to return. i2c_smbus_read_block_data() can read up to 32 bytes (I2C_SMBUS_BLOCK_MAX) and there is no safeguard on how many bytes are provided in the return value. Ensure we always have enough space for any future firmware. Also 0-initialize the values to prevent any access to uninitialized memory. Cc: # v4.4.x, v4.9.x, v4.14.x, v4.15.x, v4.16.x Signed-off-by: Benjamin Tissoires Acked-by: KT Liao Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 28fffa9066d48794171a0cd8bf37c5d6ee0dd834 Author: Mimi Zohar Date: Wed Nov 2 09:14:16 2016 -0400 Revert "ima: limit file hash setting by user to fix and log modes" commit f5acb3dcba1ffb7f0b8cbb9dba61500eea5d610b upstream. Userspace applications have been modified to write security xattrs, but they are not context aware. In the case of security.ima, the security xattr can be either a file hash or a file signature. Permitting writing one, but not the other requires the application to be context aware. In addition, userspace applications might write files to a staging area, which might not be in policy, and then change some file metadata (eg. owner) making it in policy. As a result, these files are not labeled properly. This reverts commit c68ed80c97d9720f51ef31fe91560fdd1e121533, which prevents writing file hashes as security.ima xattrs. Requested-by: Patrick Ohly Cc: Dmitry Kasatkin Signed-off-by: Mimi Zohar Cc: Mike Rapoport Signed-off-by: Greg Kroah-Hartman commit 0f929c96926569416e9d1a1a81d1c4f59d8436aa Author: Brian Foster Date: Thu Mar 15 10:51:58 2018 -0700 xfs: detect agfl count corruption and reset agfl commit a27ba2607e60312554cbcd43fc660b2c7f29dc9c upstream. The struct xfs_agfl v5 header was originally introduced with unexpected padding that caused the AGFL to operate with one less slot than intended. The header has since been packed, but the fix left an incompatibility for users who upgrade from an old kernel with the unpacked header to a newer kernel with the packed header while the AGFL happens to wrap around the end. The newer kernel recognizes one extra slot at the physical end of the AGFL that the previous kernel did not. The new kernel will eventually attempt to allocate a block from that slot, which contains invalid data, and cause a crash. This condition can be detected by comparing the active range of the AGFL to the count. While this detects a padding mismatch, it can also trigger false positives for unrelated flcount corruption. Since we cannot distinguish a size mismatch due to padding from unrelated corruption, we can't trust the AGFL enough to simply repopulate the empty slot. Instead, avoid unnecessarily complex detection logic and and use a solution that can handle any form of flcount corruption that slips through read verifiers: distrust the entire AGFL and reset it to an empty state. Any valid blocks within the AGFL are intentionally leaked. This requires xfs_repair to rectify (which was already necessary based on the state the AGFL was found in). The reset mitigates the side effect of the padding mismatch problem from a filesystem crash to a free space accounting inconsistency. The generic approach also means that this patch can be safely backported to kernels with or without a packed struct xfs_agfl. Check the AGF for an invalid freelist count on initial read from disk. If detected, set a flag on the xfs_perag to indicate that a reset is required before the AGFL can be used. In the first transaction that attempts to use a flagged AGFL, reset it to empty, warn the user about the inconsistency and allow the freelist fixup code to repopulate the AGFL with new blocks. The xfs_perag flag is cleared to eliminate the need for repeated checks on each block allocation operation. This allows kernels that include the packing fix commit 96f859d52bcb ("libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct") to handle older unpacked AGFL formats without a filesystem crash. Suggested-by: Dave Chinner Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Reviewed-by Dave Chiluk Signed-off-by: Darrick J. Wong Signed-off-by: Dave Chiluk Signed-off-by: Greg Kroah-Hartman commit 38accd6e50791d1136c0196f187523ba0eed6294 Author: Greg Kroah-Hartman Date: Thu May 31 17:58:13 2018 +0200 Revert "pinctrl: msm: Use dynamic GPIO numbering" This reverts commit 0bd77073e693e8f93ff6ddba65a9f426153221cb which is commit a7aa75a2a7dba32594291a71c3704000a2fd7089 upstream. There's been too many complaints about this. Personally I think it's going to blow up when people hit this in mainline, but hey, it's not my systems. At least we don't have to backport the mess to the stable kernels to give them some more life to live unscathed :) Reported-by: Timur Tabi Reported-by: Sebastian Gottschall Cc: Bjorn Andersson Cc: Linus Walleij Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 60a1dc530d3ab65ce07eb19d5bb630cef54a24bf Author: Geert Uytterhoeven Date: Mon Nov 21 13:19:31 2016 +0100 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type commit 009615ab7fd4e43b82a38e4e6adc5e23c1ee567f upstream. On sparc32, tcflag_t is unsigned long, unlike all other architectures: drivers/usb/serial/cp210x.c: In function 'cp210x_get_termios': drivers/usb/serial/cp210x.c:717:3: warning: passing argument 2 of 'cp210x_get_termios_port' from incompatible pointer type cp210x_get_termios_port(tty->driver_data, ^ drivers/usb/serial/cp210x.c:35:13: note: expected 'unsigned int *' but argument is of type 'tcflag_t *' static void cp210x_get_termios_port(struct usb_serial_port *port, ^ Consistently use tcflag_t to fix this. Signed-off-by: Geert Uytterhoeven Signed-off-by: Johan Hovold Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 09ae0d2ec919b2cf2e6f7dd4be034b060f12c18f Author: Michael Neuling Date: Fri May 18 11:37:42 2018 +1000 powerpc/64s: Clear PCR on boot commit faf37c44a105f3608115785f17cbbf3500f8bc71 upstream. Clear the PCR (Processor Compatibility Register) on boot to ensure we are not running in a compatibility mode. We've seen this cause problems when a crash (and kdump) occurs while running compat mode guests. The kdump kernel then runs with the PCR set and causes problems. The symptom in the kdump kernel (also seen in petitboot after fast-reboot) is early userspace programs taking sigills on newer instructions (seen in libc). Signed-off-by: Michael Neuling Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit b27fb13e93b0b41d56706c1a577759ab69d80a3f Author: Will Deacon Date: Mon May 21 17:44:57 2018 +0100 arm64: lse: Add early clobbers to some input/output asm operands commit 32c3fa7cdf0c4a3eb8405fc3e13398de019e828b upstream. For LSE atomics that read and write a register operand, we need to ensure that these operands are annotated as "early clobber" if the register is written before all of the input operands have been consumed. Failure to do so can result in the compiler allocating the same register to both operands, leading to splats such as: Unable to handle kernel paging request at virtual address 11111122222221 [...] x1 : 1111111122222222 x0 : 1111111122222221 Process swapper/0 (pid: 1, stack limit = 0x000000008209f908) Call trace: test_atomic64+0x1360/0x155c where x0 has been allocated as both the value to be stored and also the atomic_t pointer. This patch adds the missing clobbers. Cc: Cc: Dave Martin Cc: Robin Murphy Reported-by: Mark Salter Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman