CVE-2017-18075

commit b8447222eb207d5a5ec20a0f357065963dabdcd0 Author: Greg Kroah-Hartman Date: Wed Jan 10 09:31:23 2018 +0100 Linux 4.14.13 commit 77bbeea7811f0857952d3f096438ce2e1bb16f1a Author: Christian Borntraeger Date: Thu Dec 21 09:18:22 2017 +0100 KVM: s390: prevent buffer overrun on memory hotplug during migration commit c2cf265d860882b51a200e4a7553c17827f2b730 upstream. We must not go beyond the pre-allocated buffer. This can happen when a new memory slot is added during migration. Reported-by: David Hildenbrand Signed-off-by: Christian Borntraeger Fixes: 190df4a212a7 (KVM: s390: CMMA tracking, ESSA emulation, migration mode) Reviewed-by: Cornelia Huck Reviewed-by: David Hildenbrand Signed-off-by: Greg Kroah-Hartman commit 853bcadeefe18ee0661a302811a17644b1f9e80b Author: Christian Borntraeger Date: Fri Dec 15 13:14:31 2017 +0100 KVM: s390: fix cmma migration for multiple memory slots commit 32aa144fc32abfcbf7140f473dfbd94c5b9b4105 upstream. When multiple memory slots are present the cmma migration code does not allocate enough memory for the bitmap. The memory slots are sorted in reverse order, so we must use gfn and size of slot[0] instead of the last one. Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Fixes: 190df4a212a7 (KVM: s390: CMMA tracking, ESSA emulation, migration mode) Reviewed-by: Cornelia Huck Signed-off-by: Greg Kroah-Hartman commit 756ac0b046182487a2b813dd1dadb17e0d7b8b67 Author: Boris Brezillon Date: Mon Dec 18 11:32:45 2017 +0100 mtd: nand: pxa3xx: Fix READOOB implementation commit fee4380f368e84ed216b62ccd2fbc4126f2bf40b upstream. In the current driver, OOB bytes are accessed in raw mode, and when a page access is done with NDCR_SPARE_EN set and NDCR_ECC_EN cleared, the driver must read the whole spare area (64 bytes in case of a 2k page, 16 bytes for a 512 page). The driver was only reading the free OOB bytes, which was leaving some unread data in the FIFO and was somehow leading to a timeout. We could patch the driver to read ->spare_size + ->ecc_size instead of just ->spare_size when READOOB is requested, but we’d better make in-band and OOB accesses consistent. Since the driver is always accessing in-band data in non-raw mode (with the ECC engine enabled), we should also access OOB data in this mode. That’s particularly useful when using the BCH engine because in this mode the free OOB bytes are also ECC protected. Fixes: 43bcfd2bb24a (“mtd: nand: pxa3xx: Add driver-specific ECC BCH support”) Reported-by: Sean Nyekjær Tested-by: Willy Tarreau Signed-off-by: Boris Brezillon Acked-by: Ezequiel Garcia Tested-by: Sean Nyekjaer Acked-by: Robert Jarzmik Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit a0fdea2a407e0f2503f6b80b1a89c44fb58d64e9 Author: Helge Deller Date: Fri Jan 5 21:55:38 2018 +0100 parisc: qemu idle sleep support commit 310d82784fb4d60c80569f5ca9f53a7f3bf1d477 upstream. Add qemu idle sleep support when running under qemu with SeaBIOS PDC firmware. Like the power architecture we use the “or” assembler instructions, which translate to nops on real hardware, to indicate that qemu shall idle sleep. Signed-off-by: Helge Deller Cc: Richard Henderson Signed-off-by: Greg Kroah-Hartman commit fb510265edaf4809c050e620231b6ea69507fe82 Author: Helge Deller Date: Tue Jan 2 20:36:44 2018 +0100 parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel commit 88776c0e70be0290f8357019d844aae15edaa967 upstream. Qemu for PARISC reported on a 32bit SMP parisc kernel strange failures about “Not-handled unaligned insn 0x0e8011d6 and 0x0c2011c9.” Those opcodes evaluate to the ldcw() assembly instruction which requires (on 32bit) an alignment of 16 bytes to ensure atomicity. As it turns out, qemu is correct and in our assembly code in entry.S and pacache.S we don’t pay attention to the required alignment. This patch fixes the problem by aligning the lock offset in assembly code in the same manner as we do in our C-code. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit f5edee88ad430356e5c6b1c309782cce3f736272 Author: John Johansen Date: Thu Dec 7 00:28:27 2017 -0800 apparmor: fix regression in mount mediation when feature set is pinned commit 5b9f57cf47b87f07210875d6a24776b4496b818d upstream. When the mount code was refactored for Labels it was not correctly updated to check whether policy supported mediation of the mount class. This causes a regression when the kernel feature set is reported as supporting mount and policy is pinned to a feature set that does not support mount mediation. BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882697#41 Fixes: 2ea3ffb7782a (“apparmor: add mount mediation”) Reported-by: Fabian Grünbichler Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 46789641800ca2077acb66c6cbe8e2ce7575113c Author: Tom Lendacky Date: Thu Nov 30 16:46:40 2017 -0600 x86/microcode/AMD: Add support for fam17h microcode loading commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf upstream. The size for the Microcode Patch Block (MPB) for an AMD family 17h processor is 3200 bytes. Add a #define for fam17h so that it does not default to 2048 bytes and fail a microcode load/update. Signed-off-by: Tom Lendacky Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Cc: Alice Ferrazzi Signed-off-by: Greg Kroah-Hartman commit 2df832f7aa68dd1cf454d6fa165f1c61a3cd04e5 Author: Aaron Ma Date: Sat Nov 25 16:48:41 2017 -0800 Input: elantech - add new icbody type 15 commit 10d900303f1c3a821eb0bef4e7b7ece16768fba4 upstream. The touchpad of Lenovo Thinkpad L480 reports it’s version as 15. Signed-off-by: Aaron Ma Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 49b52457e1fc9cbf21ba7a3e24fcc4541e0c08d2 Author: John Sperbeck Date: Sun Dec 31 21:24:58 2017 -0800 powerpc/mm: Fix SEGV on mapped region to return SEGV_ACCERR commit ecb101aed86156ec7cd71e5dca668e09146e6994 upstream. The recent refactoring of the powerpc page fault handler in commit c3350602e876 (“powerpc/mm: Make bad_area* helper functions”) caused access to protected memory regions to indicate SEGV_MAPERR instead of the traditional SEGV_ACCERR in the si_code field of a user-space signal handler. This can confuse debug libraries that temporarily change the protection of memory regions, and expect to use SEGV_ACCERR as an indication to restore access to a region. This commit restores the previous behavior. The following program exhibits the issue: $ ./repro read || echo “FAILED” $ ./repro write || echo “FAILED” $ ./repro exec || echo “FAILED” #include #include #include #include #include #include #include static void segv_handler(int n, siginfo_t *info, void *arg) { _exit(info->si_code == SEGV_ACCERR ? 0 : 1); } int main(int argc, char **argv) { void *p = NULL; struct sigaction act = { .sa_sigaction = segv_handler, .sa_flags = SA_SIGINFO, }; assert(argc == 2); p = mmap(NULL, getpagesize(), (strcmp(argv[1], “write”) == 0) ? PROT_READ : 0, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); assert(p != MAP_FAILED); assert(sigaction(SIGSEGV, &act, NULL) == 0); if (strcmp(argv[1], “read”) == 0) printf("%c", *(unsigned char *)p); else if (strcmp(argv[1], “write”) == 0) *(unsigned char *)p = 0; else if (strcmp(argv[1], “exec”) == 0) ((void (*)(void))p)(); return 1; /* failed to generate SEGV */ } Fixes: c3350602e876 (“powerpc/mm: Make bad_area* helper functions”) Signed-off-by: John Sperbeck Acked-by: Benjamin Herrenschmidt [mpe: Add commit references in change log] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit d17237bbdf70eb2a30301eb94533fe712ba96cb0 Author: Vineet Gupta Date: Fri Dec 8 08:26:58 2017 -0800 ARC: uaccess: dont use “l” gcc inline asm constraint modifier commit 79435ac78d160e4c245544d457850a56f805ac0d upstream. This used to setup the LP_COUNT register automatically, but now has been removed. There was an earlier fix 3c7c7a2fc8811 which fixed instance in delay.h but somehow missed this one as gcc change had not made its way into production toolchains and was not pedantic as it is now ! Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 986128f3a74b45c6d7e639c950b69cdc933d1686 Author: Robin Murphy Date: Tue Jan 2 12:33:14 2018 +0000 iommu/arm-smmu-v3: Cope with duplicated Stream IDs commit 563b5cbe334e9503ab2b234e279d500fc4f76018 upstream. For PCI devices behind an aliasing PCIe-to-PCI/X bridge, the bridge alias to DevFn 0.0 on the subordinate bus may match the original RID of the device, resulting in the same SID being present in the device’s fwspec twice. This causes trouble later in arm_smmu_write_strtab_ent() when we wind up visiting the STE a second time and find it already live. Avoid the issue by giving arm_smmu_install_ste_for_dev() the cleverness to skip over duplicates. It seems mildly counterintuitive compared to preventing the duplicates from existing in the first place, but since the DT and ACPI probe paths build their fwspecs differently, this is actually the cleanest and most self-contained way to deal with it. Fixes: 8f78515425da (“iommu/arm-smmu: Implement of_xlate() for SMMUv3”) Reported-by: Tomasz Nowicki Tested-by: Tomasz Nowicki Tested-by: Jayachandran C. Signed-off-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 3ea9d6d0ad67c6a978604e5f16af5683c435e082 Author: Jean-Philippe Brucker Date: Thu Dec 14 11:03:01 2017 +0000 iommu/arm-smmu-v3: Don’t free page table ops twice commit 57d72e159b60456c8bb281736c02ddd3164037aa upstream. Kasan reports a double free when finalise_stage_fn fails: the io_pgtable ops are freed by arm_smmu_domain_finalise and then again by arm_smmu_domain_free. Prevent this by leaving pgtbl_ops empty on failure. Fixes: 48ec83bcbcf5 (“iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices”) Reviewed-by: Robin Murphy Signed-off-by: Jean-Philippe Brucker Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 289b51d3c17be8855c5b4be87d8e0e78cc70d511 Author: Oleg Nesterov Date: Fri Nov 17 15:30:08 2017 -0800 kernel/signal.c: remove the no longer needed SIGNAL_UNKILLABLE check in complete_signal() commit 426915796ccaf9c2bd9bb06dc5702225957bc2e5 upstream. complete_signal() checks SIGNAL_UNKILLABLE before it starts to destroy the thread group, today this is wrong in many ways. If nothing else, fatal_signal_pending() should always imply that the whole thread group (except ->group_exit_task if it is not NULL) is killed, this check breaks the rule. After the previous changes we can rely on sig_task_ignored(); sig_fatal(sig) && SIGNAL_UNKILLABLE can only be true if we actually want to kill this task and sig == SIGKILL OR it is traced and debugger can intercept the signal. This should hopefully fix the problem reported by Dmitry. This test-case static int init(void *arg) { for (;;) pause(); } int main(void) { char stack[16 * 1024]; for (;;) { int pid = clone(init, stack + sizeof(stack)/2, CLONE_NEWPID | SIGCHLD, NULL); assert(pid > 0); assert(ptrace(PTRACE_ATTACH, pid, 0, 0) == 0); assert(waitpid(-1, NULL, WSTOPPED) == pid); assert(ptrace(PTRACE_DETACH, pid, 0, SIGSTOP) == 0); assert(syscall(__NR_tkill, pid, SIGKILL) == 0); assert(pid == wait(NULL)); } } triggers the WARN_ON_ONCE(!(task->jobctl & JOBCTL_STOP_PENDING)) in task_participate_group_stop(). do_signal_stop()->signal_group_exit() checks SIGNAL_GROUP_EXIT and return false, but task_set_jobctl_pending() checks fatal_signal_pending() and does not set JOBCTL_STOP_PENDING. And his should fix the minor security problem reported by Kyle, SECCOMP_RET_TRACE can miss fatal_signal_pending() the same way if the task is the root of a pid namespace. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Oleg Nesterov Reported-by: Dmitry Vyukov Reported-by: Kyle Huey Reviewed-by: Kees Cook Tested-by: Kyle Huey Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 94429f353675f4e3e5fefdaf3e01a18d44074f87 Author: Oleg Nesterov Date: Fri Nov 17 15:30:04 2017 -0800 kernel/signal.c: protect the SIGNAL_UNKILLABLE tasks from !sig_kernel_only() signals commit ac25385089f673560867eb5179228a44ade0cfc1 upstream. Change sig_task_ignored() to drop the SIG_DFL && !sig_kernel_only() signals even if force == T. This simplifies the next change and this matches the same check in get_signal() which will drop these signals anyway. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Oleg Nesterov Tested-by: Kyle Huey Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2ebd69e8c251597f51768dce320cc10f9b4c8894 Author: Oleg Nesterov Date: Fri Nov 17 15:30:01 2017 -0800 kernel/signal.c: protect the traced SIGNAL_UNKILLABLE tasks from SIGKILL commit 628c1bcba204052d19b686b5bac149a644cdb72e upstream. The comment in sig_ignored() says “Tracers may want to know about even ignored signals” but SIGKILL can not be reported to debugger and it is just wrong to return 0 in this case: SIGKILL should only kill the SIGNAL_UNKILLABLE task if it comes from the parent ns. Change sig_ignored() to ignore ->ptrace if sig == SIGKILL and rely on sig_task_ignored(). SISGTOP coming from within the namespace is not really right too but at least debugger can intercept it, and we can’t drop it here because this will break "gdb -p 1": ptrace_attach() won’t work. Perhaps we will add another ->ptrace check later, we will see. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Oleg Nesterov Tested-by: Kyle Huey Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 22af48be826c4193bba2f11112330aabb2568594 Author: Rafael J. Wysocki Date: Wed Nov 15 02:13:40 2017 +0100 x86 / CPU: Always show current CPU frequency in /proc/cpuinfo commit 7d5905dc14a87805a59f3c5bf70173aac2bb18f8 upstream. After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo “cpu MHz"”) the “cpu MHz” number in /proc/cpuinfo on x86 can be either the nominal CPU frequency (which is constant) or the frequency most recently requested by a scaling governor in cpufreq, depending on the cpufreq configuration. That is somewhat inconsistent and is different from what it was before 4.13, so in order to restore the previous behavior, make it report the current CPU frequency like the scaling_cur_freq sysfs file in cpufreq. To that end, modify the /proc/cpuinfo implementation on x86 to use aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback registers, if available, and use their values to compute the CPU frequency to be reported as "cpu MHz". However, do that carefully enough to avoid accumulating delays that lead to unacceptable access times for /proc/cpuinfo on systems with many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs asynchronously at the /proc/cpuinfo open time, add a single delay upfront (if necessary) at that point and simply compute the current frequency while running show_cpuinfo() for each individual CPU. Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce the default delay between consecutive APERF and MPERF reads to 10 ms, which should be sufficient to get large enough numbers for the frequency computation in all cases. Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo “cpu MHz"”) Signed-off-by: Rafael J. Wysocki Acked-by: Thomas Gleixner Tested-by: Thomas Gleixner Acked-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit eff3e4fde76492931a45e23767c7842524b0ea06 Author: Rafael J. Wysocki Date: Mon Nov 13 02:15:39 2017 +0100 x86 / CPU: Avoid unnecessary IPIs in arch_freq_get_on_cpu() commit b29c6ef7bb1257853c1e31616d84f55e561cf631 upstream. Even though aperfmperf_snapshot_khz() caches the samples.khz value to return if called again in a sufficiently short time, its caller, arch_freq_get_on_cpu(), still uses smp_call_function_single() to run it which may allow user space to trigger an IPI storm by reading from the scaling_cur_freq cpufreq sysfs file in a tight loop. To avoid that, move the decision on whether or not to return the cached samples.khz value to arch_freq_get_on_cpu(). This change was part of commit 941f5f0f6ef5 (“x86: CPU: Fix up “cpu MHz” in /proc/cpuinfo”), but it was not the reason for the revert and it remains applicable. Fixes: 4815d3c56d1e (cpufreq: x86: Make scaling_cur_freq behave more as expected) Signed-off-by: Rafael J. Wysocki Reviewed-by: WANG Chao Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2335a22b2224f71ac639becef4a6cb8ef54c8b7e Author: David Howells Date: Tue Jan 2 10:02:19 2018 +0000 fscache: Fix the default for fscache_maybe_release_page() commit 98801506552593c9b8ac11021b0cdad12cab4f6b upstream. Fix the default for fscache_maybe_release_page() for when the cookie isn’t valid or the page isn’t cached. It mustn’t return false as that indicates the page cannot yet be freed. The problem with the default is that if, say, there’s no cache, but a network filesystem’s pages are using up almost all the available memory, a system can OOM because the filesystem ->releasepage() op will not allow them to be released as fscache_maybe_release_page() incorrectly prevents it. This can be tested by writing a sequence of 512MiB files to an AFS mount. It does not affect NFS or CIFS because both of those wrap the call in a check of PG_fscache and it shouldn’t bother Ceph as that only has PG_private set whilst writeback is in progress. This might be an issue for 9P, however. Note that the pages aren’t entirely stuck. Removing a file or unmounting will clear things because that uses ->invalidatepage() instead. Fixes: 201a15428bd5 (“FS-Cache: Handle pages pending storage that get evicted under OOM conditions”) Reported-by: Marc Dionne Signed-off-by: David Howells Reviewed-by: Jeff Layton Acked-by: Al Viro Tested-by: Marc Dionne Signed-off-by: Greg Kroah-Hartman commit 2ee35943b11f07de678642a8f08e61e5d5f3867a Author: Stefan Brüns Date: Mon Nov 27 20:05:34 2017 +0100 sunxi-rsb: Include OF based modalias in device uevent commit e2bf801ecd4e62222a46d1ba9e57e710171d29c1 upstream. Include the OF-based modalias in the uevent sent when registering devices on the sunxi RSB bus, so that user space has a chance to autoload the kernel module for the device. Fixes a regression caused by commit 3f241bfa60bd (“arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0”). When the axp20x-rsb module for the AXP803 PMIC is built as a module, it is not loaded and the system ends up with an disfunctional MMC controller. Fixes: d787dcdb9c8f (“bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus”) Acked-by: Chen-Yu Tsai Signed-off-by: Stefan Brüns Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit 5d8c5beecdd9098458a047a871cd20fae3f4c6b2 Author: Lucas De Marchi Date: Tue Jan 2 12:18:37 2018 -0800 drm/i915: Apply Display WA #1183 on skl, kbl, and cfl commit 30414f3010aff95ffdb6bed7b9dce62cde94fdc7 upstream. Display WA #1183 was recently added to workaround “Failures when enabling DPLL0 with eDP link rate 2.16 or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz (CDCLK_CTL CD Frequency Select 10b or 11b) used in this enabling or in previous enabling.” This workaround was designed to minimize the impact only to save the bad case with that link rates. But HW engineers indicated that it should be safe to apply broadly, although they were expecting the DPLL0 link rate to be unchanged on runtime. We need to cover 2 cases: when we are in fact enabling DPLL0 and when we are just changing the frequency with small differences. This is based on previous patch by Rodrigo Vivi with suggestions from Ville Syrjälä. Cc: Arthur J Runyan Cc: Ville Syrjälä Cc: Rodrigo Vivi Signed-off-by: Lucas De Marchi Reviewed-by: Ville Syrjälä Signed-off-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 53421c2fe99ce16838639ad89d772d914a119a49) [ Lucas: Backport to 4.15 adding back variable that has been removed on commits not meant to be backported ] Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit 5d8c39173bd71ed53ae88de77a8ec94f30b69919 Author: Ville Syrjälä Date: Fri Dec 8 23:37:36 2017 +0200 drm/i915: Disable DC states around GMBUS on GLK commit 3488d0237f6364614f0c59d6d784bb79b11eeb92 upstream. Prevent the DMC from destroying GMBUS transfers on GLK. GMBUS lives in PG1 so DC off is all we need. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dhinakaran Pandiyan (cherry picked from commit 156961ae7bdf6feb72778e8da83d321b273343fd) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit d4f9aaeb26d024f2f239b19a68d3e339628e1066 Author: Arnd Bergmann Date: Tue Dec 5 11:10:26 2017 +0100 crypto: chelsio - select CRYPTO_GF128MUL commit d042566d8c704e1ecec370300545d4a409222e39 upstream. Without the gf128mul library support, we can run into a link error: drivers/crypto/chelsio/chcr_algo.o: In function `chcr_update_tweak’: chcr_algo.c:(.text+0x7e0): undefined reference to `gf128mul_x8_ble’ This adds a Kconfig select statement for it, next to the ones we already have. Fixes: b8fd1f4170e7 (“crypto: chcr - Add ctr mode and process large sg entries for cipher”) Signed-off-by: Arnd Bergmann Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7156c794b8ab462705e6ac80c5fa69565eb44c62 Author: Eric Biggers Date: Wed Dec 20 14:28:25 2017 -0800 crypto: pcrypt - fix freeing pcrypt instances commit d76c68109f37cb85b243a1cf0f40313afd2bae68 upstream. pcrypt is using the old way of freeing instances, where the ->free() method specified in the ‘struct crypto_template’ is passed a pointer to the 'struct crypto_instance’. But the crypto_instance is being kfree()'d directly, which is incorrect because the memory was actually allocated as an aead_instance, which contains the crypto_instance at a nonzero offset. Thus, the wrong pointer was being kfree()'d. Fix it by switching to the new way to free aead_instance’s where the ->free() method is specified in the aead_instance itself. Reported-by: syzbot Fixes: 0496f56065e0 (“crypto: pcrypt - Add support for new AEAD interface”) Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9c36498f74533e0b1fdcb9692a04482bc2d91d8d Author: Eric Biggers Date: Mon Dec 11 12:15:17 2017 -0800 crypto: chacha20poly1305 - validate the digest size commit e57121d08c38dabec15cf3e1e2ad46721af30cae upstream. If the rfc7539 template was instantiated with a hash algorithm with digest size larger than 16 bytes (POLY1305_DIGEST_SIZE), then the digest overran the ‘tag’ buffer in 'struct chachapoly_req_ctx’, corrupting the subsequent memory, including 'cryptlen’. This caused a crash during crypto_skcipher_decrypt(). Fix it by, when instantiating the template, requiring that the underlying hash algorithm has the digest size expected for Poly1305. Reproducer: #include #include #include int main() { int algfd, reqfd; struct sockaddr_alg addr = { .salg_type = "aead", .salg_name = "rfc7539(chacha20,sha256)", }; unsigned char buf[32] = { 0 }; algfd = socket(AF_ALG, SOCK_SEQPACKET, 0); bind(algfd, (void *)&addr, sizeof(addr)); setsockopt(algfd, SOL_ALG, ALG_SET_KEY, buf, sizeof(buf)); reqfd = accept(algfd, 0, 0); write(reqfd, buf, 16); read(reqfd, buf, 16); } Reported-by: syzbot Fixes: 71ebc4d1b27d (“crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539”) Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 491062a0099c8bf6841dece8dd501d9fc2b80e34 Author: Jan Engelhardt Date: Tue Dec 19 19:09:07 2017 +0100 crypto: n2 - cure use after free commit 203f45003a3d03eea8fa28d74cfc74c354416fdb upstream. queue_cache_init is first called for the Control Word Queue (n2_crypto_probe). At that time, queue_cache[0] is NULL and a new kmem_cache will be allocated. If the subsequent n2_register_algs call fails, the kmem_cache will be released in queue_cache_destroy, but queue_cache_init[0] is not set back to NULL. So when the Module Arithmetic Unit gets probed next (n2_mau_probe), queue_cache_init will not allocate a kmem_cache again, but leave it as its bogus value, causing a BUG() to trigger when queue_cache[0] is eventually passed to kmem_cache_zalloc: n2_crypto: Found N2CP at /virtual-devices@100/n2cp@7 n2_crypto: Registered NCS HVAPI version 2.0 called queue_cache_init n2_crypto: md5 alg registration failed n2cp f028687c: /virtual-devices@100/n2cp@7: Unable to register algorithms. called queue_cache_destroy n2cp: probe of f028687c failed with error -22 n2_crypto: Found NCP at /virtual-devices@100/ncp@6 n2_crypto: Registered NCS HVAPI version 2.0 called queue_cache_init kernel BUG at mm/slab.c:2993! Call Trace: [0000000000604488] kmem_cache_alloc+0x1a8/0x1e0 (inlined) kmem_cache_zalloc (inlined) new_queue (inlined) spu_queue_setup (inlined) handle_exec_unit [0000000010c61eb4] spu_mdesc_scan+0x1f4/0x460 [n2_crypto] [0000000010c62b80] n2_mau_probe+0x100/0x220 [n2_crypto] [000000000084b174] platform_drv_probe+0x34/0xc0 Signed-off-by: Jan Engelhardt Acked-by: David S. Miller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 95a362c9a6892085f714eb6e31eea6a0e3aa93bf Author: Ard Biesheuvel Date: Tue Jan 2 17:21:10 2018 +0000 efi/capsule-loader: Reinstate virtual capsule mapping commit f24c4d478013d82bd1b943df566fff3561d52864 upstream. Commit: 82c3768b8d68 (“efi/capsule-loader: Use a cached copy of the capsule header”) … refactored the capsule loading code that maps the capsule header, to avoid having to map it several times. However, as it turns out, the vmap() call we ended up removing did not just map the header, but the entire capsule image, and dropping this virtual mapping breaks capsules that are processed by the firmware immediately (i.e., without a reboot). Unfortunately, that change was part of a larger refactor that allowed a quirk to be implemented for Quark, which has a non-standard memory layout for capsules, and we have slightly painted ourselves into a corner by allowing quirk code to mangle the capsule header and memory layout. So we need to fix this without breaking Quark. Fortunately, Quark does not appear to care about the virtual mapping, and so we can simply do a partial revert of commit: 2a457fb31df6 (“efi/capsule-loader: Use page addresses rather than struct page pointers”) … and create a vmap() mapping of the entire capsule (including header) based on the reinstated struct page array, unless running on Quark, in which case we pass the capsule header copy as before. Reported-by: Ge Song Tested-by: Bryan O’Donoghue Tested-by: Ge Song Signed-off-by: Ard Biesheuvel Cc: Dave Young Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: [email protected] Fixes: 82c3768b8d68 (“efi/capsule-loader: Use a cached copy of the capsule header”) Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b9fa21f3daa6533ab2303caad72c996e3924cf3b Author: Chris Mason Date: Fri Dec 15 11:58:27 2017 -0800 btrfs: fix refcount_t usage when deleting btrfs_delayed_nodes commit ec35e48b286959991cdbb886f1bdeda4575c80b4 upstream. refcounts have a generic implementation and an asm optimized one. The generic version has extra debugging to make sure that once a refcount goes to zero, refcount_inc won’t increase it. The btrfs delayed inode code wasn’t expecting this, and we’re tripping over the warnings when the generic refcounts are used. We ended up with this race: Process A Process B btrfs_get_delayed_node() spin_lock(root->inode_lock) radix_tree_lookup() __btrfs_release_delayed_node() refcount_dec_and_test(&delayed_node->refs) our refcount is now zero refcount_add(2) <— warning here, refcount unchanged spin_lock(root->inode_lock) radix_tree_delete() With the generic refcounts, we actually warn again when process B above tries to release his refcount because refcount_add() turned into a no-op. We saw this in production on older kernels without the asm optimized refcounts. The fix used here is to use refcount_inc_not_zero() to detect when the object is in the middle of being freed and return NULL. This is almost always the right answer anyway, since we usually end up pitching the delayed_node if it didn’t have fresh data in it. This also changes __btrfs_release_delayed_node() to remove the extra check for zero refcounts before radix tree deletion. btrfs_get_delayed_node() was the only path that was allowing refcounts to go from zero to one. Fixes: 6de5f18e7b0da (“btrfs: fix refcount_t usage when deleting btrfs_delayed_node”) Signed-off-by: Chris Mason Reviewed-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 319122a71f306943a75217b3e78a9a0f8e9c1e95 Author: Andrea Arcangeli Date: Thu Jan 4 16:18:09 2018 -0800 userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails commit 0cbb4b4f4c44f54af268969b18d8deda63aded59 upstream. The previous fix in commit 384632e67e08 (“userfaultfd: non-cooperative: fix fork use after free”) corrected the refcounting in case of UFFD_EVENT_FORK failure for the fork userfault paths. That still didn’t clear the vma->vm_userfaultfd_ctx of the vmas that were set to point to the aborted new uffd ctx earlier in dup_userfaultfd. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Andrea Arcangeli Reported-by: syzbot Reviewed-by: Mike Rapoport Cc: Eric Biggers Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c86ee796feed73dfa8a895be48c146b018d14393 Author: Baoquan He Date: Thu Jan 4 16:18:06 2018 -0800 mm/sparse.c: wrong allocation for mem_section commit d09cfbbfa0f761a97687828b5afb27b56cbf2e19 upstream. In commit 83e3c48729d9 (“mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y”) mem_section is allocated at runtime to save memory. It allocates the first dimension of array with sizeof(struct mem_section). It costs extra memory, should be sizeof(struct mem_section *). Fix it. Link: http://lkml.kernel.org/r/[email protected] Fixes: 83e3c48729 (“mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y”) Signed-off-by: Baoquan He Tested-by: Dave Young Acked-by: Kirill A. Shutemov Cc: Kirill A. Shutemov Cc: Ingo Molnar Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Atsushi Kumagai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit abcc78627877cef68144475e88952b0957406024 Author: Anshuman Khandual Date: Thu Jan 4 16:17:52 2018 -0800 mm/mprotect: add a cond_resched() inside change_pmd_range() commit 4991c09c7c812dba13ea9be79a68b4565bb1fa4e upstream. While testing on a large CPU system, detected the following RCU stall many times over the span of the workload. This problem is solved by adding a cond_resched() in the change_pmd_range() function. INFO: rcu_sched detected stalls on CPUs/tasks: 154-…: (670 ticks this GP) idle=022/140000000000000/0 softirq=2825/2825 fqs=612 (detected by 955, t=6002 jiffies, g=4486, c=4485, q=90864) Sending NMI from CPU 955 to CPUs 154: NMI backtrace for cpu 154 CPU: 154 PID: 147071 Comm: workload Not tainted 4.15.0-rc3+ #3 NIP: c0000000000b3f64 LR: c0000000000b33d4 CTR: 000000000000aa18 REGS: 00000000a4b0fb44 TRAP: 0501 Not tainted (4.15.0-rc3+) MSR: 8000000000009033 CR: 22422082 XER: 00000000 CFAR: 00000000006cf8f0 SOFTE: 1 GPR00: 0010000000000000 c00003ef9b1cb8c0 c0000000010cc600 0000000000000000 GPR04: 8e0000018c32b200 40017b3858fd6e00 8e0000018c32b208 40017b3858fd6e00 GPR08: 8e0000018c32b210 40017b3858fd6e00 8e0000018c32b218 40017b3858fd6e00 GPR12: ffffffffffffffff c00000000fb25100 NIP [c0000000000b3f64] plpar_hcall9+0x44/0x7c LR [c0000000000b33d4] pSeries_lpar_flush_hash_range+0x384/0x420 Call Trace: flush_hash_range+0x48/0x100 __flush_tlb_pending+0x44/0xd0 hpte_need_flush+0x408/0x470 change_protection_range+0xaac/0xf10 change_prot_numa+0x30/0xb0 task_numa_work+0x2d0/0x3e0 task_work_run+0x130/0x190 do_notify_resume+0x118/0x120 ret_from_except_lite+0x70/0x74 Instruction dump: 60000000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378 e9410060 e9610068 e9810070 44000022 <7d806378> e9810028 f88c0000 f8ac0008 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Anshuman Khandual Suggested-by: Nicholas Piggin Acked-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ae04ca35247af576999da5ef726d1a03fc65de09 Author: Oleg Nesterov Date: Thu Jan 4 16:17:49 2018 -0800 kernel/acct.c: fix the acct->needcheck check in check_free_space() commit 4d9570158b6260f449e317a5f9ed030c2504a615 upstream. As Tsukada explains, the time_is_before_jiffies(acct->needcheck) check is very wrong, we need time_is_after_jiffies() to make sys_acct() work. Ignoring the overflows, the code should “goto out” if needcheck > jiffies, while currently it checks “needcheck < jiffies” and thus in the likely case check_free_space() does nothing until jiffies overflow. In particular this means that sys_acct() is simply broken, acct_on() sets acct->needcheck = jiffies and expects that check_free_space() should set acct->active = 1 after the free-space check, but this won’t happen if jiffies increments in between. This was broken by commit 32dc73086015 (“get rid of timer in kern/acct.c”) in 2011, then another (correct) commit 795a2f22a8ea (“acct() should honour the limits from the very beginning”) made the problem more visible. Link: http://lkml.kernel.org/r/[email protected] Fixes: 32dc73086015 (“get rid of timer in kern/acct.c”) Reported-by: TSUKADA Koutaro Suggested-by: TSUKADA Koutaro Signed-off-by: Oleg Nesterov Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit aea4ead5aba7d0990e007d55b806b1e7859a8bed Author: Thomas Gleixner Date: Fri Jan 5 15:27:34 2018 +0100 x86/pti: Rename BUG_CPU_INSECURE to BUG_CPU_MELTDOWN commit de791821c295cc61419a06fe5562288417d1bc58 upstream. Use the name associated with the particular attack which needs page table isolation for mitigation. Signed-off-by: Thomas Gleixner Acked-by: David Woodhouse Cc: Alan Cox Cc: Jiri Koshina Cc: Linus Torvalds Cc: Tim Chen Cc: Andi Lutomirski Cc: Andi Kleen Cc: Peter Zijlstra Cc: Paul Turner Cc: Tom Lendacky Cc: Greg KH Cc: Dave Hansen Cc: Kees Cook Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801051525300.1724@nanos Signed-off-by: Greg Kroah-Hartman commit 83c7e4977221da397ac37119c50a1b21cc6a6677 Author: David Woodhouse Date: Thu Jan 4 14:37:05 2018 +0000 x86/alternatives: Add missing ‘\n’ at end of ALTERNATIVE inline asm commit b9e705ef7cfaf22db0daab91ad3cd33b0fa32eb9 upstream. Where an ALTERNATIVE is used in the middle of an inline asm block, this would otherwise lead to the following instruction being appended directly to the trailing ".popsection", and a failed compile. Fixes: 9cebed423c84 (“x86, alternative: Use .pushsection/.popsection”) Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Cc: [email protected] Cc: Rik van Riel Cc: [email protected] Cc: Tim Chen Cc: Peter Zijlstra Cc: Paul Turner Cc: Jiri Kosina Cc: Andy Lutomirski Cc: Dave Hansen Cc: Kees Cook Cc: Linus Torvalds Cc: Greg Kroah-Hartman Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 98f42e3f849412895171d096b901bfa3ff0fe004 Author: Thomas Gleixner Date: Thu Jan 4 22:19:04 2018 +0100 x86/tlb: Drop the _GPL from the cpu_tlbstate export commit 1e5476815fd7f98b888e01a0f9522b63085f96c9 upstream. The recent changes for PTI touch cpu_tlbstate from various tlb_flush inlines. cpu_tlbstate is exported as GPL symbol, so this causes a regression when building out of tree drivers for certain graphics cards. Aside of that the export was wrong since it was introduced as it should have been EXPORT_PER_CPU_SYMBOL_GPL(). Use the correct PER_CPU export and drop the _GPL to restore the previous state which allows users to utilize the cards they payed for. As always I’m really thrilled to make this kind of change to support the #friends (or however the hot hashtag of today is spelled) from that closet sauce graphics corp. Fixes: 1e02ce4cccdc (“x86: Store a per-cpu shadow copy of CR4”) Fixes: 6fd166aae78c (“x86/mm: Use/Fix PCID to optimize user/kernel switches”) Reported-by: Kees Cook Signed-off-by: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Peter Zijlstra Cc: Andy Lutomirski Signed-off-by: Greg Kroah-Hartman commit b4660939afccbe1d2af5d066d1337f1b29c87ae8 Author: Peter Zijlstra Date: Thu Jan 4 18:07:12 2018 +0100 x86/events/intel/ds: Use the proper cache flush method for mapping ds buffers commit 42f3bdc5dd962a5958bc024c1e1444248a6b8b4a upstream. Thomas reported the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: ovsdb-server/4498 caller is native_flush_tlb_single+0x57/0xc0 native_flush_tlb_single+0x57/0xc0 __set_pte_vaddr+0x2d/0x40 set_pte_vaddr+0x2f/0x40 cea_set_pte+0x30/0x40 ds_update_cea.constprop.4+0x4d/0x70 reserve_ds_buffers+0x159/0x410 x86_reserve_hardware+0x150/0x160 x86_pmu_event_init+0x3e/0x1f0 perf_try_init_event+0x69/0x80 perf_event_alloc+0x652/0x740 SyS_perf_event_open+0x3f6/0xd60 do_syscall_64+0x5c/0x190 set_pte_vaddr is used to map the ds buffers into the cpu entry area, but there are two problems with that: 1) The resulting flush is not supposed to be called in preemptible context 2) The cpu entry area is supposed to be per CPU, but the debug store buffers are mapped for all CPUs so these mappings need to be flushed globally. Add the necessary preemption protection across the mapping code and flush TLBs globally. Fixes: c1961a4631da (“x86/events/intel/ds: Map debug buffers in cpu_entry_area”) Reported-by: Thomas Zeitlhofer Signed-off-by: Peter Zijlstra Signed-off-by: Thomas Gleixner Tested-by: Thomas Zeitlhofer Cc: Greg Kroah-Hartman Cc: Hugh Dickins Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 67f67244f80a37fba03c9e6011853dba94952c7c Author: Thomas Gleixner Date: Thu Jan 4 12:32:03 2018 +0100 x86/kaslr: Fix the vaddr_end mess commit 1dddd25125112ba49706518ac9077a1026a18f37 upstream. vaddr_end for KASLR is only documented in the KASLR code itself and is adjusted depending on config options. So it’s not surprising that a change of the memory layout causes KASLR to have the wrong vaddr_end. This can map arbitrary stuff into other areas causing hard to understand problems. Remove the whole ifdef magic and define the start of the cpu_entry_area to be the end of the KASLR vaddr range. Add documentation to that effect. Fixes: 92a0f81d8957 (“x86/cpu_entry_area: Move it out of the fixmap”) Reported-by: Benjamin Gilbert Signed-off-by: Thomas Gleixner Tested-by: Benjamin Gilbert Cc: Andy Lutomirski Cc: Greg Kroah-Hartman Cc: Dave Hansen Cc: Peter Zijlstra Cc: Thomas Garnier Cc: Alexander Kuleshov Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801041320360.1771@nanos Signed-off-by: Greg Kroah-Hartman commit 1af9b74bfa59250f69578f6e6424aae7cb46d063 Author: Thomas Gleixner Date: Thu Jan 4 13:01:40 2018 +0100 x86/mm: Map cpu_entry_area at the same place on 4/5 level commit f2078904810373211fb15f91888fba14c01a4acc upstream. There is no reason for 4 and 5 level pagetables to have a different layout. It just makes determining vaddr_end for KASLR harder than necessary. Fixes: 92a0f81d8957 (“x86/cpu_entry_area: Move it out of the fixmap”) Signed-off-by: Thomas Gleixner Cc: Andy Lutomirski Cc: Benjamin Gilbert Cc: Greg Kroah-Hartman Cc: Dave Hansen Cc: Peter Zijlstra Cc: Thomas Garnier Cc: Alexander Kuleshov Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801041320360.1771@nanos Signed-off-by: Greg Kroah-Hartman commit 7adf28df2f0bdeb2141f6e8edc2b746d4a6cc11f Author: Andrey Ryabinin Date: Thu Dec 28 19:06:20 2017 +0300 x86/mm: Set MODULES_END to 0xffffffffff000000 commit f5a40711fa58f1c109165a4fec6078bf2dfd2bdc upstream. Since f06bdd4001c2 (“x86/mm: Adapt MODULES_END based on fixmap section size”) kasan_mem_to_shadow(MODULES_END) could be not aligned to a page boundary. So passing page unaligned address to kasan_populate_zero_shadow() have two possible effects: 1) It may leave one page hole in supposed to be populated area. After commit 21506525fb8d (“x86/kasan/64: Teach KASAN about the cpu_entry_area”) that hole happens to be in the shadow covering fixmap area and leads to crash: BUG: unable to handle kernel paging request at fffffbffffe8ee04 RIP: 0010:check_memory_region+0x5c/0x190 Call Trace: memcpy+0x1f/0x50 ghes_copy_tofrom_phys+0xab/0x180 ghes_read_estatus+0xfb/0x280 ghes_notify_nmi+0x2b2/0x410 nmi_handle+0x115/0x2c0 default_do_nmi+0x57/0x110 do_nmi+0xf8/0x150 end_repeat_nmi+0x1a/0x1e Note, the crash likely disappeared after commit 92a0f81d8957, which changed kasan_populate_zero_shadow() call the way it was before commit 21506525fb8d. 2) Attempt to load module near MODULES_END will fail, because __vmalloc_node_range() called from kasan_module_alloc() will hit the WARN_ON(!pte_none(*pte)) in the vmap_pte_range() and bail out with error. To fix this we need to make kasan_mem_to_shadow(MODULES_END) page aligned which means that MODULES_END should be 8*PAGE_SIZE aligned. The whole point of commit f06bdd4001c2 was to move MODULES_END down if NR_CPUS is big, so the cpu_entry_area takes a lot of space. But since 92a0f81d8957 (“x86/cpu_entry_area: Move it out of the fixmap”) the cpu_entry_area is no longer in fixmap, so we could just set MODULES_END to a fixed 8*PAGE_SIZE aligned address. Fixes: f06bdd4001c2 (“x86/mm: Adapt MODULES_END based on fixmap section size”) Reported-by: Jakub Kicinski Signed-off-by: Andrey Ryabinin Signed-off-by: Thomas Gleixner Cc: Andy Lutomirski Cc: Thomas Garnier Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman