1. 17 Dec, 2018 1 commit
  2. 13 Dec, 2018 1 commit
  3. 08 Dec, 2018 2 commits
  4. 27 Nov, 2018 1 commit
  5. 21 Nov, 2018 1 commit
  6. 13 Nov, 2018 1 commit
    • Waiman Long's avatar
      locking/lockdep: Fix debug_locks off performance problem · 81301a15
      Waiman Long authored
      [ Upstream commit 9506a7425b094d2f1d9c877ed5a78f416669269b ]
      It was found that when debug_locks was turned off because of a problem
      found by the lockdep code, the system performance could drop quite
      significantly when the lock_stat code was also configured into the
      kernel. For instance, parallel kernel build time on a 4-socket x86-64
      server nearly doubled.
      Further analysis into the cause of the slowdown traced back to the
      frequent call to debug_locks_off() from the __lock_acquired() function
      probably due to some inconsistent lockdep states with debug_locks
      off. The debug_locks_off() function did an unconditional atomic xchg
      to write a 0 value into debug_locks which had already been set to 0.
      This led to severe cacheline contention in the cacheline that held
      debug_locks.  As debug_locks is being referenced in quite a few different
      places in the kernel, this greatly slow down the system performance.
      To prevent that trashing of debug_locks cacheline, lock_acquired()
      and lock_contended() now checks the state of debug_locks before
      proceeding. The debug_locks_off() function is also modified to check
      debug_locks before calling __debug_locks_off().
      Signed-off-by: 's avatarWaiman Long <longman@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Link: http://lkml.kernel.org/r/1539913518-15598-1-git-send-email-longman@redhat.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. 10 Nov, 2018 1 commit
  8. 18 Oct, 2018 1 commit
  9. 04 Oct, 2018 1 commit
    • Bart Van Assche's avatar
      scsi: klist: Make it safe to use klists in atomic context · 4a67b822
      Bart Van Assche authored
      [ Upstream commit 624fa7790f80575a4ec28fbdb2034097dc18d051 ]
      In the scsi_transport_srp implementation it cannot be avoided to
      iterate over a klist from atomic context when using the legacy block
      layer instead of blk-mq. Hence this patch that makes it safe to use
      klists in atomic context. This patch avoids that lockdep reports the
      WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
       Possible interrupt unsafe locking scenario:
             CPU0                    CPU1
             ----                    ----
      stack backtrace:
      Workqueue: kblockd blk_timeout_work
      Call Trace:
       srp_timed_out+0xaf/0x1d0 [scsi_transport_srp]
       scsi_times_out+0xd4/0x410 [scsi_mod]
      See also commit c9ddf73476ff ("scsi: scsi_transport_srp: Fix shost to
      rport translation").
      Signed-off-by: 's avatarBart Van Assche <bart.vanassche@wdc.com>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: James Bottomley <jejb@linux.vnet.ibm.com>
      Acked-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: 's avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. 15 Sep, 2018 1 commit
  11. 17 Aug, 2018 1 commit
    • Chintan Pandya's avatar
      ioremap: Update pgtable free interfaces with addr · 6e6b6377
      Chintan Pandya authored
      commit 785a19f9d1dd8a4ab2d0633be4656653bd3de1fc upstream.
      The following kernel panic was observed on ARM64 platform due to a stale
      TLB entry.
       1. ioremap with 4K size, a valid pte page table is set.
       2. iounmap it, its pte entry is set to 0.
       3. ioremap the same address with 2M size, update its pmd entry with
          a new value.
       4. CPU may hit an exception because the old pmd entry is still in TLB,
          which leads to a kernel panic.
      Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
      table") has addressed this panic by falling to pte mappings in the above
      case on ARM64.
      To support pmd mappings in all cases, TLB purge needs to be performed
      in this case on ARM64.
      Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
      so that TLB purge can be added later in seprate patches.
      [toshi.kani@hpe.com: merge changes, rewrite patch description]
      Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
      Signed-off-by: 's avatarChintan Pandya <cpandya@codeaurora.org>
      Signed-off-by: 's avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Cc: mhocko@suse.com
      Cc: akpm@linux-foundation.org
      Cc: hpa@zytor.com
      Cc: linux-mm@kvack.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: stable@vger.kernel.org
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20180627141348.21777-3-toshi.kani@hpe.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. 25 Jul, 2018 1 commit
  13. 03 Jul, 2018 1 commit
    • Geert Uytterhoeven's avatar
      lib/vsprintf: Remove atomic-unsafe support for %pCr · ec7bea37
      Geert Uytterhoeven authored
      commit 666902e42fd8344b923c02dc5b0f37948ff4f225 upstream.
      "%pCr" formats the current rate of a clock, and calls clk_get_rate().
      The latter obtains a mutex, hence it must not be called from atomic
      Remove support for this rarely-used format, as vsprintf() (and e.g.
      printk()) must be callable from any context.
      Any remaining out-of-tree users will start seeing the clock's name
      printed instead of its rate.
      Reported-by: 's avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Fixes: 900cca29 ("lib/vsprintf: add %pC{,n,r} format specifiers for clocks")
      Link: http://lkml.kernel.org/r/1527845302-12159-5-git-send-email-geert+renesas@glider.be
      To: Jia-Ju Bai <baijiaju1990@gmail.com>
      To: Jonathan Corbet <corbet@lwn.net>
      To: Michael Turquette <mturquette@baylibre.com>
      To: Stephen Boyd <sboyd@kernel.org>
      To: Zhang Rui <rui.zhang@intel.com>
      To: Eduardo Valentin <edubezval@gmail.com>
      To: Eric Anholt <eric@anholt.net>
      To: Stefan Wahren <stefan.wahren@i2se.com>
      To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linux-doc@vger.kernel.org
      Cc: linux-clk@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Cc: linux-serial@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-renesas-soc@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: 's avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: 's avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. 30 May, 2018 1 commit
    • Yonghong Song's avatar
      bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y · ee4bba56
      Yonghong Song authored
      [ Upstream commit 09584b40 ]
      With CONFIG_BPF_JIT_ALWAYS_ON is defined in the config file,
      tools/testing/selftests/bpf/test_kmod.sh failed like below:
        [root@localhost bpf]# ./test_kmod.sh
        sysctl: setting key "net.core.bpf_jit_enable": Invalid argument
        [ JIT enabled:0 hardened:0 ]
        [  132.175681] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
        [  132.458834] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
        [ JIT enabled:1 hardened:0 ]
        [  133.456025] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
        [  133.730935] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
        [ JIT enabled:1 hardened:1 ]
        [  134.769730] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
        [  135.050864] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
        [ JIT enabled:1 hardened:2 ]
        [  136.442882] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
        [  136.821810] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
        [root@localhost bpf]#
      The test_kmod.sh load/remove test_bpf.ko multiple times with different
      settings for sysctl net.core.bpf_jit_{enable,harden}. The failed test #297
      of test_bpf.ko is designed such that JIT always fails.
      Commit 290af866 (bpf: introduce BPF_JIT_ALWAYS_ON config)
      introduced the following tightening logic:
              if (!bpf_prog_is_dev_bound(fp->aux)) {
                      fp = bpf_int_jit_compile(fp);
          #ifdef CONFIG_BPF_JIT_ALWAYS_ON
                      if (!fp->jited) {
                              *err = -ENOTSUPP;
                              return fp;
      With this logic, Test #297 always gets return value -ENOTSUPP
      when CONFIG_BPF_JIT_ALWAYS_ON is defined, causing the test failure.
      This patch fixed the failure by marking Test #297 as expected failure
      when CONFIG_BPF_JIT_ALWAYS_ON is defined.
      Fixes: 290af866 (bpf: introduce BPF_JIT_ALWAYS_ON config)
      Signed-off-by: 's avatarYonghong Song <yhs@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. 01 May, 2018 1 commit
    • Dmitry Vyukov's avatar
      kobject: don't use WARN for registration failures · 6ab44135
      Dmitry Vyukov authored
      commit 3e14c6abbfb5c94506edda9d8e2c145d79375798 upstream.
      This WARNING proved to be noisy. The function still returns an error
      and callers should handle it. That's how most of kernel code works.
      Downgrade the WARNING to pr_err() and leave WARNINGs for kernel bugs.
      Signed-off-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Reported-by: syzbot+209c0f67f99fec8eb14b@syzkaller.appspotmail.com
      Reported-by: syzbot+7fb6d9525a4528104e05@syzkaller.appspotmail.com
      Reported-by: syzbot+2e63711063e2d8f9ea27@syzkaller.appspotmail.com
      Reported-by: syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.com
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. 31 Mar, 2018 1 commit
  17. 28 Mar, 2018 1 commit
    • Toshi Kani's avatar
      mm/vmalloc: add interfaces to free unmapped page table · 9c7f7bdb
      Toshi Kani authored
      commit b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e upstream.
      On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may
      create pud/pmd mappings.  A kernel panic was observed on arm64 systems
      with Cortex-A75 in the following steps as described by Hanjun Guo.
       1. ioremap a 4K size, valid page table will build,
       2. iounmap it, pte0 will set to 0;
       3. ioremap the same address with 2M size, pgd/pmd is unchanged,
          then set the a new value for pmd;
       4. pte0 is leaked;
       5. CPU may meet exception because the old pmd is still in TLB,
          which will lead to kernel panic.
      This panic is not reproducible on x86.  INVLPG, called from iounmap,
      purges all levels of entries associated with purged address on x86.  x86
      still has memory leak.
      The patch changes the ioremap path to free unmapped page table(s) since
      doing so in the unmap path has the following issues:
       - The iounmap() path is shared with vunmap(). Since vmap() only
         supports pte mappings, making vunmap() to free a pte page is an
         overhead for regular vmap users as they do not need a pte page freed
       - Checking if all entries in a pte page are cleared in the unmap path
         is racy, and serializing this check is expensive.
       - The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
         Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
      Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which
      clear a given pud/pmd entry and free up a page for the lower level
      This patch implements their stub functions on x86 and arm64, which work
      as workaround.
      [akpm@linux-foundation.org: fix typo in pmd_free_pte_page() stub]
      Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com
      Fixes: e61ce6ad ("mm: change ioremap to set up huge I/O mappings")
      Reported-by: 's avatarLei Li <lious.lilei@hisilicon.com>
      Signed-off-by: 's avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Wang Xuefeng <wxf.wang@hisilicon.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Chintan Pandya <cpandya@codeaurora.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. 03 Mar, 2018 1 commit
    • James Hogan's avatar
      lib/mpi: Fix umul_ppmm() for MIPS64r6 · d9868db6
      James Hogan authored
      [ Upstream commit bbc25bee ]
      Current MIPS64r6 toolchains aren't able to generate efficient
      DMULU/DMUHU based code for the C implementation of umul_ppmm(), which
      performs an unsigned 64 x 64 bit multiply and returns the upper and
      lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit
      inputs to 128-bits and emits a __multi3 intrinsic call to perform a 128
      x 128 multiply. This is both inefficient, and it results in a link error
      since we don't include __multi3 in MIPS linux.
      For example commit 90a53e44 ("cfg80211: implement regdb signature
      checking") merged in v4.15-rc1 recently broke the 64r6_defconfig and
      64r6el_defconfig builds by indirectly selecting MPILIB. The same build
      errors can be reproduced on older kernels by enabling e.g. CRYPTO_RSA:
      lib/mpi/generic_mpih-mul1.o: In function `mpihelp_mul_1':
      lib/mpi/generic_mpih-mul1.c:50: undefined reference to `__multi3'
      lib/mpi/generic_mpih-mul2.o: In function `mpihelp_addmul_1':
      lib/mpi/generic_mpih-mul2.c:49: undefined reference to `__multi3'
      lib/mpi/generic_mpih-mul3.o: In function `mpihelp_submul_1':
      lib/mpi/generic_mpih-mul3.c:49: undefined reference to `__multi3'
      lib/mpi/mpih-div.o In function `mpihelp_divrem':
      lib/mpi/mpih-div.c:205: undefined reference to `__multi3'
      lib/mpi/mpih-div.c:142: undefined reference to `__multi3'
      Therefore add an efficient MIPS64r6 implementation of umul_ppmm() using
      inline assembly and the DMULU/DMUHU instructions, to prevent __multi3
      calls being emitted.
      Fixes: 7fd08ca5 ("MIPS: Add build support for the MIPS R6 ISA")
      Signed-off-by: 's avatarJames Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-mips@linux-mips.org
      Cc: linux-crypto@vger.kernel.org
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. 25 Feb, 2018 2 commits
    • Arnd Bergmann's avatar
      kasan: rework Kconfig settings · ef3af346
      Arnd Bergmann authored
      commit e7c52b84 upstream.
      We get a lot of very large stack frames using gcc-7.0.1 with the default
      -fsanitize-address-use-after-scope --param asan-stack=1 options, which can
      easily cause an overflow of the kernel stack, e.g.
        drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes
        drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes
        lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes
        drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes
        drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes
        fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes
      To reduce this risk, -fsanitize-address-use-after-scope is now split out
      into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
      frames that are smaller than 2 kilobytes most of the time on x86_64.  An
      earlier version of this patch also prevented combining KASAN_EXTRA with
      KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.
      All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
      and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can
      bring back that default now.  KASAN_EXTRA=y still causes lots of
      warnings but now defaults to !COMPILE_TEST to disable it in
      allmodconfig, and it remains disabled in all other defconfigs since it
      is a new option.  I arbitrarily raise the warning limit for KASAN_EXTRA
      to 3072 to reduce the noise, but an allmodconfig kernel still has around
      50 warnings on gcc-7.
      I experimented a bit more with smaller stack frames and have another
      follow-up series that reduces the warning limit for 64-bit architectures
      to 1280 bytes (without CONFIG_KASAN).
      With earlier versions of this patch series, I also had patches to address
      the warnings we get with KASAN and/or KASAN_EXTRA, using a
      "noinline_if_stackbloat" annotation.
      That annotation now got replaced with a gcc-8 bugfix (see
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
      older compilers, which means that KASAN_EXTRA is now just as bad as
      before and will lead to an instant stack overflow in a few extreme
      This reverts parts of commit 3f181b4d ("lib/Kconfig.debug: disable
      -Wframe-larger-than warnings with KASAN=y").  Two patches in linux-next
      should be merged first to avoid introducing warnings in an allmodconfig
        3cd890db ("media: dvb-frontends: fix i2c access helpers for KASAN")
        16c3ada8 ("media: r820t: fix r820t_write_reg for KASAN")
      Do we really need to backport this?
      I think we do: without this patch, enabling KASAN will lead to
      unavoidable kernel stack overflow in certain device drivers when built
      with gcc-7 or higher on linux-4.10+ or any version that contains a
      backport of commit c5caf21a.  Most people are probably still on
      older compilers, but it will get worse over time as they upgrade their
      The warnings we get on kernels older than this should all be for code
      that uses dangerously large stack frames, though most of them do not
      cause an actual stack overflow by themselves.The asan-stack option was
      added in linux-4.0, and commit 3f181b4d ("lib/Kconfig.debug:
      disable -Wframe-larger-than warnings with KASAN=y") effectively turned
      off the warning for allmodconfig kernels, so I would like to see this
      fix backported to any kernels later than 4.0.
      I have done dozens of fixes for individual functions with stack frames
      larger than 2048 bytes with asan-stack, and I plan to make sure that
      all those fixes make it into the stable kernels as well (most are
      already there).
      Part of the complication here is that asan-stack (from 4.0) was
      originally assumed to always require much larger stacks, but that
      turned out to be a combination of multiple gcc bugs that we have now
      worked around and fixed, but sanitize-address-use-after-scope (from
      v4.10) has a much higher inherent stack usage and also suffers from at
      least three other problems that we have analyzed but not yet fixed
      upstream, each of them makes the stack usage more severe than it should
      Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.deSigned-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: 's avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      [arnd: rebase to v4.9; only re-enable warning]
      Signed-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Biggers's avatar
      509: fix printing uninitialized stack memory when OID is empty · d39838a5
      Eric Biggers authored
      [ Upstream commit 8dfd2f22 ]
      Callers of sprint_oid() do not check its return value before printing
      the result.  In the case where the OID is zero-length, -EBADMSG was
      being returned without anything being written to the buffer, resulting
      in uninitialized stack memory being printed.  Fix this by writing
      "(bad)" to the buffer in the cases where -EBADMSG is returned.
      Fixes: 4f73175d ("X.509: Add utility functions to render OIDs as strings")
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  20. 17 Feb, 2018 2 commits
  21. 31 Jan, 2018 1 commit
    • Alexei Starovoitov's avatar
      bpf: introduce BPF_JIT_ALWAYS_ON config · a3d6dd6a
      Alexei Starovoitov authored
      [ upstream commit 290af866 ]
      The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.
      A quote from goolge project zero blog:
      "At this point, it would normally be necessary to locate gadgets in
      the host kernel code that can be used to actually leak data by reading
      from an attacker-controlled location, shifting and masking the result
      appropriately and then using the result of that as offset to an
      attacker-controlled address for a load. But piecing gadgets together
      and figuring out which ones work in a speculation context seems annoying.
      So instead, we decided to use the eBPF interpreter, which is built into
      the host kernel - while there is no legitimate way to invoke it from inside
      a VM, the presence of the code in the host kernel's text section is sufficient
      to make it usable for the attack, just like with ordinary ROP gadgets."
      To make attacker job harder introduce BPF_JIT_ALWAYS_ON config
      option that removes interpreter from the kernel in favor of JIT-only mode.
      So far eBPF JIT is supported by:
      x64, arm64, arm32, sparc64, s390, powerpc64, mips64
      The start of JITed program is randomized and code page is marked as read-only.
      In addition "constant blinding" can be turned on with net.core.bpf_jit_harden
      - move __bpf_prog_ret0 under ifdef (Daniel)
      - fix init order, test_bpf and cBPF (Daniel's feedback)
      - fix offloaded bpf (Jakub's feedback)
      - add 'return 0' dummy in case something can invoke prog->bpf_func
      - retarget bpf tree. For bpf-next the patch would need one extra hunk.
        It will be sent when the trees are merged back to net-next
      Considered doing:
        int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT;
      but it seems better to land the patch as-is and in bpf-next remove
      bpf_jit_enable global variable from all JITs, consolidate in one place
      and remove this jit_init() function.
      Signed-off-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  22. 14 Dec, 2017 4 commits
  23. 30 Nov, 2017 1 commit
    • Eric Biggers's avatar
      lib/mpi: call cond_resched() from mpi_powm() loop · 443d26a6
      Eric Biggers authored
      commit 1d9ddde1 upstream.
      On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the
      largest permitted inputs (16384 bits), the kernel spends 10+ seconds
      doing modular exponentiation in mpi_powm() without rescheduling.  If all
      threads do it, it locks up the system.  Moreover, it can cause
      rcu_sched-stall warnings.
      Notwithstanding the insanity of doing this calculation in kernel mode
      rather than in userspace, fix it by calling cond_resched() as each bit
      from the exponent is processed.  It's still noninterruptible, but at
      least it's preemptible now.
      Do the cond_resched() once per bit rather than once per MPI limb because
      each limb might still easily take 100+ milliseconds on slow CPUs.
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  24. 15 Nov, 2017 1 commit
    • Eric Biggers's avatar
      KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] · 8ea52a68
      Eric Biggers authored
      commit 624f5ab8 upstream.
      syzkaller reported a NULL pointer dereference in asn1_ber_decoder().  It
      can be reproduced by the following command, assuming
              keyctl add pkcs7_test desc '' @s
      The bug is that if the data buffer is empty, an integer underflow occurs
      in the following check:
              if (unlikely(dp >= datalen - 1))
                      goto data_overrun_error;
      This results in the NULL data pointer being dereferenced.
      Fix it by checking for 'datalen - dp < 2' instead.
      Also fix the similar check for 'dp >= datalen - n' later in the same
      function.  That one possibly could result in a buffer overread.
      The NULL pointer dereference was reproducible using the "pkcs7_test" key
      type but not the "asymmetric" key type because the "asymmetric" key type
      checks for a 0-length payload before calling into the ASN.1 decoder but
      the "pkcs7_test" key type does not.
      The bug report was:
          BUG: unable to handle kernel NULL pointer dereference at           (null)
          IP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233
          PGD 7b708067 P4D 7b708067 PUD 7b6ee067 PMD 0
          Oops: 0000 [#1] SMP
          Modules linked in:
          CPU: 0 PID: 522 Comm: syz-executor1 Not tainted 4.14.0-rc8 #7
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014
          task: ffff9b6b3798c040 task.stack: ffff9b6b37970000
          RIP: 0010:asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233
          RSP: 0018:ffff9b6b37973c78 EFLAGS: 00010216
          RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000021c
          RDX: ffffffff814a04ed RSI: ffffb1524066e000 RDI: ffffffff910759e0
          RBP: ffff9b6b37973d60 R08: 0000000000000001 R09: ffff9b6b3caa4180
          R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002
          R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
          FS:  00007f10ed1f2700(0000) GS:ffff9b6b3ea00000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 0000000000000000 CR3: 000000007b6f3000 CR4: 00000000000006f0
          Call Trace:
           pkcs7_parse_message+0xee/0x240 crypto/asymmetric_keys/pkcs7_parser.c:139
           verify_pkcs7_signature+0x33/0x180 certs/system_keyring.c:216
           pkcs7_preparse+0x41/0x70 crypto/asymmetric_keys/pkcs7_key_type.c:63
           key_create_or_update+0x180/0x530 security/keys/key.c:855
           SYSC_add_key security/keys/keyctl.c:122 [inline]
           SyS_add_key+0xbf/0x250 security/keys/keyctl.c:62
          RIP: 0033:0x4585c9
          RSP: 002b:00007f10ed1f1bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000f8
          RAX: ffffffffffffffda RBX: 00007f10ed1f2700 RCX: 00000000004585c9
          RDX: 0000000020000000 RSI: 0000000020008ffb RDI: 0000000020008000
          RBP: 0000000000000000 R08: ffffffffffffffff R09: 0000000000000000
          R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff1b2260ae
          R13: 00007fff1b2260af R14: 00007f10ed1f2700 R15: 0000000000000000
          Code: dd ca ff 48 8b 45 88 48 83 e8 01 4c 39 f0 0f 86 a8 07 00 00 e8 53 dd ca ff 49 8d 46 01 48 89 85 58 ff ff ff 48 8b 85 60 ff ff ff <42> 0f b6 0c 30 89 c8 88 8d 75 ff ff ff 83 e0 1f 89 8d 28 ff ff
          RIP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: ffff9b6b37973c78
          CR2: 0000000000000000
      Fixes: 42d5ec27 ("X.509: Add an ASN.1 decoder")
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  25. 09 Nov, 2017 1 commit
    • Philippe Gerum's avatar
      lib/ipipe: make dump_stack() domain-aware · a68e4abb
      Philippe Gerum authored
      When dumping a stack backtrace, we neither need nor want to disable
      root stage IRQs over the head stage, where CPU migration can't
      Conversely, we neither need nor want to disable hard IRQs from the
      head stage, so that latency won't skyrocket either.
  26. 08 Nov, 2017 1 commit
    • Eric Biggers's avatar
      KEYS: fix out-of-bounds read during ASN.1 parsing · cb14a0dd
      Eric Biggers authored
      commit 2eb9eabf upstream.
      syzkaller with KASAN reported an out-of-bounds read in
      asn1_ber_decoder().  It can be reproduced by the following command,
          keyctl add asymmetric desc $'\x30\x30' @s
      The bug is that the length of an ASN.1 data value isn't validated in the
      case where it is encoded using the short form, causing the decoder to
      read past the end of the input buffer.  Fix it by validating the length.
      The bug report was:
          BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
          Read of size 1 at addr ffff88003cccfa02 by task syz-executor0/6818
          CPU: 1 PID: 6818 Comm: syz-executor0 Not tainted 4.14.0-rc7-00008-g5f479447 #2
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
          Call Trace:
           __dump_stack lib/dump_stack.c:16 [inline]
           dump_stack+0xb3/0x10b lib/dump_stack.c:52
           print_address_description+0x79/0x2a0 mm/kasan/report.c:252
           kasan_report_error mm/kasan/report.c:351 [inline]
           kasan_report+0x236/0x340 mm/kasan/report.c:409
           __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
           asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
           x509_cert_parse+0x1db/0x650 crypto/asymmetric_keys/x509_cert_parser.c:89
           x509_key_preparse+0x64/0x7a0 crypto/asymmetric_keys/x509_public_key.c:174
           asymmetric_key_preparse+0xcb/0x1a0 crypto/asymmetric_keys/asymmetric_type.c:388
           key_create_or_update+0x347/0xb20 security/keys/key.c:855
           SYSC_add_key security/keys/keyctl.c:122 [inline]
           SyS_add_key+0x1cd/0x340 security/keys/keyctl.c:62
          RIP: 0033:0x447c89
          RSP: 002b:00007fca7a5d3bd8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8
          RAX: ffffffffffffffda RBX: 00007fca7a5d46cc RCX: 0000000000447c89
          RDX: 0000000020006f4a RSI: 0000000020006000 RDI: 0000000020001ff5
          RBP: 0000000000000046 R08: fffffffffffffffd R09: 0000000000000000
          R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000000000
          R13: 0000000000000000 R14: 00007fca7a5d49c0 R15: 00007fca7a5d4700
      Fixes: 42d5ec27 ("X.509: Add an ASN.1 decoder")
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  27. 02 Nov, 2017 1 commit
    • David Howells's avatar
      assoc_array: Fix a buggy node-splitting case · 67bcc5e5
      David Howells authored
      commit ea678998 upstream.
      This fixes CVE-2017-12193.
      Fix a case in the assoc_array implementation in which a new leaf is
      added that needs to go into a node that happens to be full, where the
      existing leaves in that node cluster together at that level to the
      exclusion of new leaf.
      What needs to happen is that the existing leaves get moved out to a new
      node, N1, at level + 1 and the existing node needs replacing with one,
      N0, that has pointers to the new leaf and to N1.
      The code that tries to do this gets this wrong in two ways:
       (1) The pointer that should've pointed from N0 to N1 is set to point
           recursively to N0 instead.
       (2) The backpointer from N0 needs to be set correctly in the case N0 is
           either the root node or reached through a shortcut.
      Fix this by removing this path and using the split_node path instead,
      which achieves the same end, but in a more general way (thanks to Eric
      Biggers for spotting the redundancy).
      The problem manifests itself as:
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
        IP: assoc_array_apply_edit+0x59/0xe5
      Fixes: 3cb98950 ("Add a generic associative array implementation.")
      Reported-and-tested-by: 's avatarWU Fan <u3536072@connect.hku.hk>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  28. 27 Oct, 2017 1 commit
  29. 12 Oct, 2017 1 commit
    • Sergey Senozhatsky's avatar
      lib/ratelimit.c: use deferred printk() version · 1c089129
      Sergey Senozhatsky authored
      commit 656d61ce upstream.
      printk_ratelimit() invokes ___ratelimit() which may invoke a normal
      printk() (pr_warn() in this particular case) to warn about suppressed
      output.  Given that printk_ratelimit() may be called from anywhere, that
      pr_warn() is dangerous - it may end up deadlocking the system.  Fix
      ___ratelimit() by using deferred printk().
      Sasha reported the following lockdep error:
       : Unregister pv shared memory for cpu 8
       : select_fallback_rq: 3 callbacks suppressed
       : process 8583 (trinity-c78) no longer affine to cpu8
       : ======================================================
       : WARNING: possible circular locking dependency detected
       : 4.14.0-rc2-next-20170927+ #252 Not tainted
       : ------------------------------------------------------
       : migration/8/62 is trying to acquire lock:
       : (&port_lock_key){-.-.}, at: serial8250_console_write()
       : but task is already holding lock:
       : (&rq->lock){-.-.}, at: sched_cpu_dying()
       : which lock already depends on the new lock.
       : the existing dependency chain (in reverse order) is:
       : -> #3 (&rq->lock){-.-.}:
       : __lock_acquire()
       : lock_acquire()
       : _raw_spin_lock()
       : task_fork_fair()
       : sched_fork()
       : copy_process.part.31()
       : _do_fork()
       : kernel_thread()
       : rest_init()
       : start_kernel()
       : x86_64_start_reservations()
       : x86_64_start_kernel()
       : verify_cpu()
       : -> #2 (&p->pi_lock){-.-.}:
       : __lock_acquire()
       : lock_acquire()
       : _raw_spin_lock_irqsave()
       : try_to_wake_up()
       : default_wake_function()
       : woken_wake_function()
       : __wake_up_common()
       : __wake_up_common_lock()
       : __wake_up()
       : tty_wakeup()
       : tty_port_default_wakeup()
       : tty_port_tty_wakeup()
       : uart_write_wakeup()
       : serial8250_tx_chars()
       : serial8250_handle_irq.part.25()
       : serial8250_default_handle_irq()
       : serial8250_interrupt()
       : __handle_irq_event_percpu()
       : handle_irq_event_percpu()
       : handle_irq_event()
       : handle_level_irq()
       : handle_irq()
       : do_IRQ()
       : ret_from_intr()
       : native_safe_halt()
       : default_idle()
       : arch_cpu_idle()
       : default_idle_call()
       : do_idle()
       : cpu_startup_entry()
       : rest_init()
       : start_kernel()
       : x86_64_start_reservations()
       : x86_64_start_kernel()
       : verify_cpu()
       : -> #1 (&tty->write_wait){-.-.}:
       : __lock_acquire()
       : lock_acquire()
       : _raw_spin_lock_irqsave()
       : __wake_up_common_lock()
       : __wake_up()
       : tty_wakeup()
       : tty_port_default_wakeup()
       : tty_port_tty_wakeup()
       : uart_write_wakeup()
       : serial8250_tx_chars()
       : serial8250_handle_irq.part.25()
       : serial8250_default_handle_irq()
       : serial8250_interrupt()
       : __handle_irq_event_percpu()
       : handle_irq_event_percpu()
       : handle_irq_event()
       : handle_level_irq()
       : handle_irq()
       : do_IRQ()
       : ret_from_intr()
       : native_safe_halt()
       : default_idle()
       : arch_cpu_idle()
       : default_idle_call()
       : do_idle()
       : cpu_startup_entry()
       : rest_init()
       : start_kernel()
       : x86_64_start_reservations()
       : x86_64_start_kernel()
       : verify_cpu()
       : -> #0 (&port_lock_key){-.-.}:
       : check_prev_add()
       : __lock_acquire()
       : lock_acquire()
       : _raw_spin_lock_irqsave()
       : serial8250_console_write()
       : univ8250_console_write()
       : console_unlock()
       : vprintk_emit()
       : vprintk_default()
       : vprintk_func()
       : printk()
       : ___ratelimit()
       : __printk_ratelimit()
       : select_fallback_rq()
       : sched_cpu_dying()
       : cpuhp_invoke_callback()
       : take_cpu_down()
       : multi_cpu_stop()
       : cpu_stopper_thread()
       : smpboot_thread_fn()
       : kthread()
       : ret_from_fork()
       : other info that might help us debug this:
       : Chain exists of:
       :   &port_lock_key --> &p->pi_lock --> &rq->lock
       :  Possible unsafe locking scenario:
       :        CPU0                    CPU1
       :        ----                    ----
       :   lock(&rq->lock);
       :                                lock(&p->pi_lock);
       :                                lock(&rq->lock);
       :   lock(&port_lock_key);
       :  *** DEADLOCK ***
       : 4 locks held by migration/8/62:
       : #0: (&p->pi_lock){-.-.}, at: sched_cpu_dying()
       : #1: (&rq->lock){-.-.}, at: sched_cpu_dying()
       : #2: (printk_ratelimit_state.lock){....}, at: ___ratelimit()
       : #3: (console_lock){+.+.}, at: vprintk_emit()
       : stack backtrace:
       : CPU: 8 PID: 62 Comm: migration/8 Not tainted 4.14.0-rc2-next-20170927+ #252
       : Call Trace:
       : dump_stack()
       : print_circular_bug()
       : check_prev_add()
       : ? add_lock_to_list.isra.26()
       : ? check_usage()
       : ? kvm_clock_read()
       : ? kvm_sched_clock_read()
       : ? sched_clock()
       : ? check_preemption_disabled()
       : __lock_acquire()
       : ? __lock_acquire()
       : ? add_lock_to_list.isra.26()
       : ? debug_check_no_locks_freed()
       : ? memcpy()
       : lock_acquire()
       : ? serial8250_console_write()
       : _raw_spin_lock_irqsave()
       : ? serial8250_console_write()
       : serial8250_console_write()
       : ? serial8250_start_tx()
       : ? lock_acquire()
       : ? memcpy()
       : univ8250_console_write()
       : console_unlock()
       : ? __down_trylock_console_sem()
       : vprintk_emit()
       : vprintk_default()
       : vprintk_func()
       : printk()
       : ? show_regs_print_info()
       : ? lock_acquire()
       : ___ratelimit()
       : __printk_ratelimit()
       : select_fallback_rq()
       : sched_cpu_dying()
       : ? sched_cpu_starting()
       : ? rcutree_dying_cpu()
       : ? sched_cpu_starting()
       : cpuhp_invoke_callback()
       : ? cpu_disable_common()
       : take_cpu_down()
       : ? trace_hardirqs_off_caller()
       : ? cpuhp_invoke_callback()
       : multi_cpu_stop()
       : ? __this_cpu_preempt_check()
       : ? cpu_stop_queue_work()
       : cpu_stopper_thread()
       : ? cpu_stop_create()
       : smpboot_thread_fn()
       : ? sort_range()
       : ? schedule()
       : ? __kthread_parkme()
       : kthread()
       : ? sort_range()
       : ? kthread_create_on_node()
       : ret_from_fork()
       : process 9121 (trinity-c78) no longer affine to cpu8
       : smpboot: CPU 8 is now offline
      Link: http://lkml.kernel.org/r/20170928120405.18273-1-sergey.senozhatsky@gmail.com
      Fixes: 6b1d174b ("ratelimit: extend to print suppressed messages on release")
      Signed-off-by: 's avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reported-by: 's avatarSasha Levin <levinsasha928@gmail.com>
      Reviewed-by: 's avatarPetr Mladek <pmladek@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  30. 07 Sep, 2017 1 commit
  31. 02 Sep, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      lz4: fix bogus gcc warning · 529ada21
      Greg Kroah-Hartman authored
      When building lz4 under gcc-7 we get the following bogus warning:
        CC [M]  lib/lz4/lz4hc_compress.o
      lib/lz4/lz4hc_compress.c: In function ‘lz4hc_compress’:
      lib/lz4/lz4hc_compress.c:179:42: warning: ‘delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
          chaintable[(size_t)(ptr) & MAXD_MASK] = delta;
      lib/lz4/lz4hc_compress.c:134:6: note: ‘delta’ was declared here
        u16 delta;
      This doesn't show up in the 4.4-stable tree due to us turning off
      warnings like this.  It also doesn't show up in newer kernel versions as
      this code was totally rewritten.
      So for now, to get the 4.9-stable tree to build with 0 warnings on x86
      allmodconfig, let's just shut the compiler up by initializing the
      variable to 0, despite it not really doing anything.
      To be far, this code is crazy complex, so the fact that gcc can't
      determine if the variable is really used or not isn't that bad, I'd
      blame the code here instead of the compiler.
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  32. 11 Aug, 2017 1 commit
  33. 21 Jul, 2017 1 commit
  34. 05 Jul, 2017 1 commit