1. 25 Feb, 2018 13 commits
    • Wanpeng Li's avatar
      KVM: x86: fix escape of guest dr6 to the host · 9435c32b
      Wanpeng Li authored
      commit efdab992 upstream.
      
      syzkaller reported:
      
         WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 do_debug+0x222/0x250
         CPU: 0 PID: 12927 Comm: syz-executor Tainted: G           OE    4.15.0-rc2+ #16
         RIP: 0010:do_debug+0x222/0x250
         Call Trace:
          <#DB>
          debug+0x3e/0x70
         RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20
          </#DB>
          _copy_from_user+0x5b/0x90
          SyS_timer_create+0x33/0x80
          entry_SYSCALL_64_fastpath+0x23/0x9a
      
      The testcase sets a watchpoint (with perf_event_open) on a buffer that is
      passed to timer_create() as the struct sigevent argument.  In timer_create(),
      copy_from_user()'s rep movsb triggers the BP.  The testcase also sets
      the debug registers for the guest.
      
      However, KVM only restores host debug registers when the host has active
      watchpoints, which triggers a race condition when running the testcase with
      multiple threads.  The guest's DR6.BS bit can escape to the host before
      another thread invokes timer_create(), and do_debug() complains.
      
      The fix is to respect do_debug()'s dr6 invariant when leaving KVM.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9435c32b
    • Eric Biggers's avatar
      crypto: x86/twofish-3way - Fix %rbp usage · 6bfbf2aa
      Eric Biggers authored
      commit d8c7fe9f upstream.
      
      Using %rbp as a temporary register breaks frame pointer convention and
      breaks stack traces when unwinding from an interrupt in the crypto code.
      
      In twofish-3way, we can't simply replace %rbp with another register
      because there are none available.  Instead, we use the stack to hold the
      values that %rbp, %r11, and %r12 were holding previously.  Each of these
      values represents the half of the output from the previous Feistel round
      that is being passed on unchanged to the following round.  They are only
      used once per round, when they are exchanged with %rax, %rbx, and %rcx.
      
      As a result, we free up 3 registers (one per block) and can reassign
      them so that %rbp is not used, and additionally %r14 and %r15 are not
      used so they do not need to be saved/restored.
      
      There may be a small overhead caused by replacing 'xchg REG, REG' with
      the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per
      round.  But, counterintuitively, when I tested "ctr-twofish-3way" on a
      Haswell processor, the new version was actually about 2% faster.
      (Perhaps 'xchg' is not as well optimized as plain moves.)
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bfbf2aa
    • Paul Moore's avatar
      selinux: skip bounded transition processing if the policy isn't loaded · 002924ab
      Paul Moore authored
      commit 4b14752e upstream.
      
      We can't do anything reasonable in security_bounded_transition() if we
      don't have a policy loaded, and in fact we could run into problems
      with some of the code inside expecting a policy.  Fix these problems
      like we do many others in security/selinux/ss/services.c by checking
      to see if the policy is loaded (ss_initialized) and returning quickly
      if it isn't.
      Reported-by: default avatarsyzbot <syzkaller-bugs@googlegroups.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Reviewed-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      002924ab
    • Paul Moore's avatar
      selinux: ensure the context is NUL terminated in security_context_to_sid_core() · d6233121
      Paul Moore authored
      commit ef28df55 upstream.
      
      The syzbot/syzkaller automated tests found a problem in
      security_context_to_sid_core() during early boot (before we load the
      SELinux policy) where we could potentially feed context strings without
      NUL terminators into the strcmp() function.
      
      We already guard against this during normal operation (after the SELinux
      policy has been loaded) by making a copy of the context strings and
      explicitly adding a NUL terminator to the end.  The patch extends this
      protection to the early boot case (no loaded policy) by moving the context
      copy earlier in security_context_to_sid_core().
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Reviewed-By: default avatarWilliam Roberts <william.c.roberts@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6233121
    • David Howells's avatar
      Provide a function to create a NUL-terminated string from unterminated data · 4dbb8e38
      David Howells authored
      commit f3515741 upstream.
      
      Provide a function, kmemdup_nul(), that will create a NUL-terminated string
      from an unterminated character array where the length is known in advance.
      
      This is better than kstrndup() in situations where we already know the
      string length as the strnlen() in kstrndup() is superfluous.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dbb8e38
    • Chris Wilson's avatar
      drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all · 016cf65f
      Chris Wilson authored
      commit d18d1a5a upstream.
      
      To acquire all modeset locks requires a ww_ctx to be allocated. As this
      is the legacy path and the allocation small, to reduce the changes
      required (and complex untested error handling) to the legacy drivers, we
      simply assume that the allocation succeeds. At present, it relies on the
      too-small-to-fail rule, but syzbot found that by injecting a failure
      here we would hit the WARN. Document that this allocation must succeed
      with __GFP_NOFAIL.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171031115535.15166-1-chris@chris-wilson.co.ukSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      016cf65f
    • Jens Axboe's avatar
      blktrace: fix unlocked registration of tracepoints · 28de9389
      Jens Axboe authored
      commit a6da0024 upstream.
      
      We need to ensure that tracepoints are registered and unregistered
      with the users of them. The existing atomic count isn't enough for
      that. Add a lock around the tracepoints, so we serialize access
      to them.
      
      This fixes cases where we have multiple users setting up and
      tearing down tracepoints, like this:
      
      CPU: 0 PID: 2995 Comm: syzkaller857118 Not tainted
      4.14.0-rc5-next-20171018+ #36
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:16 [inline]
        dump_stack+0x194/0x257 lib/dump_stack.c:52
        panic+0x1e4/0x41c kernel/panic.c:183
        __warn+0x1c4/0x1e0 kernel/panic.c:546
        report_bug+0x211/0x2d0 lib/bug.c:183
        fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:177
        do_trap_no_signal arch/x86/kernel/traps.c:211 [inline]
        do_trap+0x260/0x390 arch/x86/kernel/traps.c:260
        do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:297
        do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:310
        invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
      RIP: 0010:tracepoint_add_func kernel/tracepoint.c:210 [inline]
      RIP: 0010:tracepoint_probe_register_prio+0x397/0x9a0 kernel/tracepoint.c:283
      RSP: 0018:ffff8801d1d1f6c0 EFLAGS: 00010293
      RAX: ffff8801d22e8540 RBX: 00000000ffffffef RCX: ffffffff81710f07
      RDX: 0000000000000000 RSI: ffffffff85b679c0 RDI: ffff8801d5f19818
      RBP: ffff8801d1d1f7c8 R08: ffffffff81710c10 R09: 0000000000000004
      R10: ffff8801d1d1f6b0 R11: 0000000000000003 R12: ffffffff817597f0
      R13: 0000000000000000 R14: 00000000ffffffff R15: ffff8801d1d1f7a0
        tracepoint_probe_register+0x2a/0x40 kernel/tracepoint.c:304
        register_trace_block_rq_insert include/trace/events/block.h:191 [inline]
        blk_register_tracepoints+0x1e/0x2f0 kernel/trace/blktrace.c:1043
        do_blk_trace_setup+0xa10/0xcf0 kernel/trace/blktrace.c:542
        blk_trace_setup+0xbd/0x180 kernel/trace/blktrace.c:564
        sg_ioctl+0xc71/0x2d90 drivers/scsi/sg.c:1089
        vfs_ioctl fs/ioctl.c:45 [inline]
        do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:685
        SYSC_ioctl fs/ioctl.c:700 [inline]
        SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
        entry_SYSCALL_64_fastpath+0x1f/0xbe
      RIP: 0033:0x444339
      RSP: 002b:00007ffe05bb5b18 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00000000006d66c0 RCX: 0000000000444339
      RDX: 000000002084cf90 RSI: 00000000c0481273 RDI: 0000000000000009
      RBP: 0000000000000082 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000206 R12: ffffffffffffffff
      R13: 00000000c0481273 R14: 0000000000000000 R15: 0000000000000000
      
      since we can now run these in parallel. Ensure that the exported helpers
      for doing this are grabbing the queue trace mutex.
      Reported-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28de9389
    • Cong Wang's avatar
      xfrm: check id proto in validate_tmpl() · 40cda9b7
      Cong Wang authored
      commit 6a53b759 upstream.
      
      syzbot reported a kernel warning in xfrm_state_fini(), which
      indicates that we have entries left in the list
      net->xfrm.state_all whose proto is zero. And
      xfrm_id_proto_match() doesn't consider them as a match with
      IPSEC_PROTO_ANY in this case.
      
      Proto with value 0 is probably not a valid value, at least
      verify_newsa_info() doesn't consider it valid either.
      
      This patch fixes it by checking the proto value in
      validate_tmpl() and rejecting invalid ones, like what iproute2
      does in xfrm_xfrmproto_getbyname().
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40cda9b7
    • Steffen Klassert's avatar
      xfrm: Fix stack-out-of-bounds read on socket policy lookup. · 7800c76f
      Steffen Klassert authored
      commit ddc47e44 upstream.
      
      When we do tunnel or beet mode, we pass saddr and daddr from the
      template to xfrm_state_find(), this is ok. On transport mode,
      we pass the addresses from the flowi, assuming that the IP
      addresses (and address family) don't change during transformation.
      This assumption is wrong in the IPv4 mapped IPv6 case, packet
      is IPv4 and template is IPv6.
      
      Fix this by catching address family missmatches of the policy
      and the flow already before we do the lookup.
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7800c76f
    • Tetsuo Handa's avatar
      mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed. · 0de023ab
      Tetsuo Handa authored
      commit bb422a73 upstream.
      
      Syzbot caught an oops at unregister_shrinker() because combination of
      commit 1d3d4437 ("vmscan: per-node deferred work") and fault
      injection made register_shrinker() fail and the caller of
      register_shrinker() did not check for failure.
      
      ----------
      [  554.881422] FAULT_INJECTION: forcing a failure.
      [  554.881422] name failslab, interval 1, probability 0, space 0, times 0
      [  554.881438] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82
      [  554.881443] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      [  554.881445] Call Trace:
      [  554.881459]  dump_stack+0x194/0x257
      [  554.881474]  ? arch_local_irq_restore+0x53/0x53
      [  554.881486]  ? find_held_lock+0x35/0x1d0
      [  554.881507]  should_fail+0x8c0/0xa40
      [  554.881522]  ? fault_create_debugfs_attr+0x1f0/0x1f0
      [  554.881537]  ? check_noncircular+0x20/0x20
      [  554.881546]  ? find_next_zero_bit+0x2c/0x40
      [  554.881560]  ? ida_get_new_above+0x421/0x9d0
      [  554.881577]  ? find_held_lock+0x35/0x1d0
      [  554.881594]  ? __lock_is_held+0xb6/0x140
      [  554.881628]  ? check_same_owner+0x320/0x320
      [  554.881634]  ? lock_downgrade+0x990/0x990
      [  554.881649]  ? find_held_lock+0x35/0x1d0
      [  554.881672]  should_failslab+0xec/0x120
      [  554.881684]  __kmalloc+0x63/0x760
      [  554.881692]  ? lock_downgrade+0x990/0x990
      [  554.881712]  ? register_shrinker+0x10e/0x2d0
      [  554.881721]  ? trace_event_raw_event_module_request+0x320/0x320
      [  554.881737]  register_shrinker+0x10e/0x2d0
      [  554.881747]  ? prepare_kswapd_sleep+0x1f0/0x1f0
      [  554.881755]  ? _down_write_nest_lock+0x120/0x120
      [  554.881765]  ? memcpy+0x45/0x50
      [  554.881785]  sget_userns+0xbcd/0xe20
      (...snipped...)
      [  554.898693] kasan: CONFIG_KASAN_INLINE enabled
      [  554.898724] kasan: GPF could be caused by NULL-ptr deref or user memory access
      [  554.898732] general protection fault: 0000 [#1] SMP KASAN
      [  554.898737] Dumping ftrace buffer:
      [  554.898741]    (ftrace buffer empty)
      [  554.898743] Modules linked in:
      [  554.898752] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82
      [  554.898755] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      [  554.898760] task: ffff8801d1dbe5c0 task.stack: ffff8801c9e38000
      [  554.898772] RIP: 0010:__list_del_entry_valid+0x7e/0x150
      [  554.898775] RSP: 0018:ffff8801c9e3f108 EFLAGS: 00010246
      [  554.898780] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [  554.898784] RDX: 0000000000000000 RSI: ffff8801c53c6f98 RDI: ffff8801c53c6fa0
      [  554.898788] RBP: ffff8801c9e3f120 R08: 1ffff100393c7d55 R09: 0000000000000004
      [  554.898791] R10: ffff8801c9e3ef70 R11: 0000000000000000 R12: 0000000000000000
      [  554.898795] R13: dffffc0000000000 R14: 1ffff100393c7e45 R15: ffff8801c53c6f98
      [  554.898800] FS:  0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
      [  554.898804] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
      [  554.898807] CR2: 00000000dbc23000 CR3: 00000001c7269000 CR4: 00000000001406e0
      [  554.898813] DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
      [  554.898816] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
      [  554.898818] Call Trace:
      [  554.898828]  unregister_shrinker+0x79/0x300
      [  554.898837]  ? perf_trace_mm_vmscan_writepage+0x750/0x750
      [  554.898844]  ? down_write+0x87/0x120
      [  554.898851]  ? deactivate_super+0x139/0x1b0
      [  554.898857]  ? down_read+0x150/0x150
      [  554.898864]  ? check_same_owner+0x320/0x320
      [  554.898875]  deactivate_locked_super+0x64/0xd0
      [  554.898883]  deactivate_super+0x141/0x1b0
      ----------
      
      Since allowing register_shrinker() callers to call unregister_shrinker()
      when register_shrinker() failed can simplify error recovery path, this
      patch makes unregister_shrinker() no-op when register_shrinker() failed.
      Also, reset shrinker->nr_deferred in case unregister_shrinker() was
      by error called twice.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarAliaksei Karaliou <akaraliou.dev@gmail.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Glauber Costa <glauber@scylladb.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0de023ab
    • Johannes Berg's avatar
      cfg80211: check dev_set_name() return value · 941095c5
      Johannes Berg authored
      commit 59b179b4 upstream.
      
      syzbot reported a warning from rfkill_alloc(), and after a while
      I think that the reason is that it was doing fault injection and
      the dev_set_name() failed, leaving the name NULL, and we didn't
      check the return value and got to rfkill_alloc() with a NULL name.
      Since we really don't want a NULL name, we ought to check the
      return value.
      
      Fixes: fb28ad35 ("net: struct device - replace bus_id with dev_name(), dev_set_name()")
      Reported-by: syzbot+1ddfb3357e1d7bb5b5d3@syzkaller.appspotmail.com
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      941095c5
    • Paolo Abeni's avatar
      net: replace dst_cache ip6_tunnel implementation with the generic one · b8c7f80c
      Paolo Abeni authored
      commit 607f725f upstream.
      
      This also fix a potential race into the existing tunnel code, which
      could lead to the wrong dst to be permanenty cached:
      
      CPU1:					CPU2:
        <xmit on ip6_tunnel>
        <cache lookup fails>
        dst = ip6_route_output(...)
      					<tunnel params are changed via nl>
      					dst_cache_reset() // no effect,
      							// the cache is empty
        dst_cache_set() // the wrong dst
      	// is permanenty stored
      	// into the cache
      
      With the new dst implementation the above race is not possible
      since the first cache lookup after dst_cache_reset will fail due
      to the timestamp check
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Suggested-and-acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarManoj Boopathi Raj <manojboopathi@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8c7f80c
    • Paolo Abeni's avatar
      net: add dst_cache support · d365b297
      Paolo Abeni authored
      commit 911362c7 upstream.
      
      This patch add a generic, lockless dst cache implementation.
      The need for lock is avoided updating the dst cache fields
      only in per cpu scope, and requiring that the cache manipulation
      functions are invoked with the local bh disabled.
      
      The refresh_ts and reset_ts fields are used to ensure the cache
      consistency in case of cuncurrent cache update (dst_cache_set*) and
      reset operation (dst_cache_reset).
      
      Consider the following scenario:
      
      CPU1:                                   	CPU2:
        <cache lookup with emtpy cache: it fails>
        <get dst via uncached route lookup>
      						<related configuration changes>
                                              	dst_cache_reset()
        dst_cache_set()
      
      The dst entry set passed to dst_cache_set() should not be used
      for later dst cache lookup, because it's obtained using old
      configuration values.
      
      Since the refresh_ts is updated only on dst_cache lookup, the
      cached value in the above scenario will be discarded on the next
      lookup.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Suggested-and-acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarManoj Boopathi Raj <manojboopathi@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d365b297
  2. 22 Feb, 2018 27 commits