1. 25 Feb, 2018 21 commits
    • Takashi Iwai's avatar
      ALSA: line6: Add a sanity check for invalid EPs · 90bca371
      Takashi Iwai authored
      commit 2a4340c5 upstream.
      
      As syzkaller spotted, currently line6 drivers submit a URB with the
      fixed EP without checking whether it's actually available, which may
      result in a kernel warning like:
        usb 1-1: BOGUS urb xfer, pipe 3 != type 1
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 24 at drivers/usb/core/urb.c:449
        usb_submit_urb+0xf8a/0x11d0
        Modules linked in:
        CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc2-42613-g1488251d1a98 #238
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        Workqueue: usb_hub_wq hub_event
        Call Trace:
         line6_start_listen+0x55f/0x9e0 sound/usb/line6/driver.c:82
         line6_init_cap_control sound/usb/line6/driver.c:690
         line6_probe+0x7c9/0x1310 sound/usb/line6/driver.c:764
         podhd_probe+0x64/0x70 sound/usb/line6/podhd.c:474
         usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
         ....
      
      This patch adds a sanity check of validity of EPs at the device
      initialization phase for avoiding the call with an invalid EP.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90bca371
    • Chris Wilson's avatar
      drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all · 8c666e64
      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>
      8c666e64
    • Jan Kara's avatar
      dnotify: Handle errors from fsnotify_add_mark_locked() in fcntl_dirnotify() · 3587188a
      Jan Kara authored
      commit b3a00660 upstream.
      
      fsnotify_add_mark_locked() can fail but we do not check its return
      value. This didn't matter before commit 9dd813c1 "fsnotify: Move
      mark list head from object into dedicated structure" as none of possible
      failures could happen for dnotify but after that commit -ENOMEM can be
      returned. Handle this error properly in fcntl_dirnotify() as
      otherwise we just hit BUG_ON(dn_mark->dn) in dnotify_free_mark().
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Reported-by: syzkaller
      Fixes: 9dd813c1Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3587188a
    • Jens Axboe's avatar
      blktrace: fix unlocked registration of tracepoints · 90f9a1ff
      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>
      90f9a1ff
    • Xin Long's avatar
      sctp: set frag_point in sctp_setsockopt_maxseg correctly · 2df0d6de
      Xin Long authored
      commit ecca8f88 upstream.
      
      Now in sctp_setsockopt_maxseg user_frag or frag_point can be set with
      val >= 8 and val <= SCTP_MAX_CHUNK_LEN. But both checks are incorrect.
      
      val >= 8 means frag_point can even be less than SCTP_DEFAULT_MINSEGMENT.
      Then in sctp_datamsg_from_user(), when it's value is greater than cookie
      echo len and trying to bundle with cookie echo chunk, the first_len will
      overflow.
      
      The worse case is when it's value is equal as cookie echo len, first_len
      becomes 0, it will go into a dead loop for fragment later on. In Hangbin
      syzkaller testing env, oom was even triggered due to consecutive memory
      allocation in that loop.
      
      Besides, SCTP_MAX_CHUNK_LEN is the max size of the whole chunk, it should
      deduct the data header for frag_point or user_frag check.
      
      This patch does a proper check with SCTP_DEFAULT_MINSEGMENT subtracting
      the sctphdr and datahdr, SCTP_MAX_CHUNK_LEN subtracting datahdr when
      setting frag_point via sockopt. It also improves sctp_setsockopt_maxseg
      codes.
      Suggested-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Reported-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2df0d6de
    • Cong Wang's avatar
      xfrm: check id proto in validate_tmpl() · 4d4d5566
      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>
      4d4d5566
    • Steffen Klassert's avatar
      xfrm: Fix stack-out-of-bounds read on socket policy lookup. · 70c5e41f
      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>
      70c5e41f
    • Leon Romanovsky's avatar
      RDMA/netlink: Fix general protection fault · d6b36a26
      Leon Romanovsky authored
      commit d0e312fe upstream.
      
      The RDMA netlink core code checks validity of messages by ensuring
      that type and operand are in range. It works well for almost all
      clients except NLDEV, which has cb_table less than number of operands.
      
      Request to access such operand will trigger the following kernel panic.
      
      This patch updates all places where cb_table is declared for the
      consistency, but only NLDEV is actually need it.
      
      general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
      Modules linked in:
      CPU: 0 PID: 522 Comm: syz-executor6 Not tainted 4.13.0+ #4
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
      task: ffff8800657799c0 task.stack: ffff8800695d000
      RIP: 0010:rdma_nl_rcv_msg+0x13a/0x4c0
      RSP: 0018:ffff8800695d7838 EFLAGS: 00010207
      RAX: dffffc0000000000 RBX: 1ffff1000d2baf0b RCX: 00000000704ff4d7
      RDX: 0000000000000000 RSI: ffffffff81ddb03c RDI: 00000003827fa6bc
      RBP: ffff8800695d7900 R08: ffffffff82ec0578 R09: 0000000000000000
      R10: ffff8800695d7900 R11: 0000000000000001 R12: 000000000000001c
      R13: ffff880069d31e00 R14: 00000000ffffffff R15: ffff880069d357c0
      FS:  00007fee6acb8700(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000201a9000 CR3: 0000000059766000 CR4: 00000000000006b0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ? rdma_nl_multicast+0x80/0x80
       rdma_nl_rcv+0x36b/0x4d0
       ? ibnl_put_attr+0xc0/0xc0
       netlink_unicast+0x4bd/0x6d0
       ? netlink_sendskb+0x50/0x50
       ? drop_futex_key_refs.isra.4+0x68/0xb0
       netlink_sendmsg+0x9ab/0xbd0
       ? nlmsg_notify+0x140/0x140
       ? wake_up_q+0xa1/0xf0
       ? drop_futex_key_refs.isra.4+0x68/0xb0
       sock_sendmsg+0x88/0xd0
       sock_write_iter+0x228/0x3c0
       ? sock_sendmsg+0xd0/0xd0
       ? do_futex+0x3e5/0xb20
       ? iov_iter_init+0xaf/0x1d0
       __vfs_write+0x46e/0x640
       ? sched_clock_cpu+0x1b/0x190
       ? __vfs_read+0x620/0x620
       ? __fget+0x23a/0x390
       ? rw_verify_area+0xca/0x290
       vfs_write+0x192/0x490
       SyS_write+0xde/0x1c0
       ? SyS_read+0x1c0/0x1c0
       ? trace_hardirqs_on_thunk+0x1a/0x1c
       entry_SYSCALL_64_fastpath+0x18/0xad
      RIP: 0033:0x7fee6a74a219
      RSP: 002b:00007fee6acb7d58 EFLAGS: 00000212 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000638000 RCX: 00007fee6a74a219
      RDX: 0000000000000078 RSI: 0000000020141000 RDI: 0000000000000006
      RBP: 0000000000000046 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000212 R12: ffff8800695d7f98
      R13: 0000000020141000 R14: 0000000000000006 R15: 00000000ffffffff
      Code: d6 48 b8 00 00 00 00 00 fc ff df 66 41 81 e4 ff 03 44 8d 72 ff 4a 8d 3c b5 c0 a6 7f 82 44 89 b5 4c ff ff ff 48 89 f9 48 c1 e9 03 <0f> b6 0c 01 48 89 f8 83 e0 07 83 c0 03 38 c8 7c 08 84 c9 0f 85
      RIP: rdma_nl_rcv_msg+0x13a/0x4c0 RSP: ffff8800695d7838
      ---[ end trace ba085d123959c8ec ]---
      Kernel panic - not syncing: Fatal exception
      
      Cc: syzkaller <syzkaller@googlegroups.com>
      Fixes: b4c598a6 ("RDMA/netlink: Implement nldev device dumpit calback")
      Reviewed-by: default avatarMark Bloch <markb@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      d6b36a26
    • Lan Tianyu's avatar
      KVM/x86: Check input paging mode when cs.l is set · 846666fa
      Lan Tianyu authored
      commit f2981033 upstream.
      
      Reported by syzkaller:
          WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 x86_emulate_insn+0x557/0x15f0 [kvm]
          Modules linked in: kvm_intel kvm [last unloaded: kvm]
          CPU: 0 PID: 27962 Comm: syz-executor Tainted: G    B   W        4.15.0-rc2-next-20171208+ #32
          Hardware name: Intel Corporation S1200SP/S1200SP, BIOS S1200SP.86B.01.03.0006.040720161253 04/07/2016
          RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
          RSP: 0018:ffff8807234476d0 EFLAGS: 00010282
          RAX: 0000000000000000 RBX: ffff88072d0237a0 RCX: ffffffffa0065c4d
          RDX: 1ffff100e5a046f9 RSI: 0000000000000003 RDI: ffff88072d0237c8
          RBP: ffff880723447728 R08: ffff88072d020000 R09: ffffffffa008d240
          R10: 0000000000000002 R11: ffffed00e7d87db3 R12: ffff88072d0237c8
          R13: ffff88072d023870 R14: ffff88072d0238c2 R15: ffffffffa008d080
          FS:  00007f8a68666700(0000) GS:ffff880802200000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 000000002009506c CR3: 000000071fec4005 CR4: 00000000003626f0
          Call Trace:
           x86_emulate_instruction+0x3bc/0xb70 [kvm]
           ? reexecute_instruction.part.162+0x130/0x130 [kvm]
           vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
           ? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
           ? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
           ? wait_lapic_expire+0x25/0x270 [kvm]
           vcpu_enter_guest+0x720/0x1ef0 [kvm]
           ...
      
      When CS.L is set, vcpu should run in the 64 bit paging mode.
      Current kvm set_sregs function doesn't have such check when
      userspace inputs sreg values. This will lead unexpected behavior.
      This patch is to add checks for CS.L, EFER.LME, EFER.LMA and
      CR4.PAE when get SREG inputs from userspace in order to avoid
      unexpected behavior.
      Suggested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Jim Mattson <jmattson@google.com>
      Signed-off-by: default avatarTianyu Lan <tianyu.lan@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      846666fa
    • Tetsuo Handa's avatar
      mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed. · 7880fc54
      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>
      7880fc54
    • Florian Westphal's avatar
      xfrm: skip policies marked as dead while rehashing · 8e754b4e
      Florian Westphal authored
      commit 862591bf upstream.
      
      syzkaller triggered following KASAN splat:
      
      BUG: KASAN: slab-out-of-bounds in xfrm_hash_rebuild+0xdbe/0xf00 net/xfrm/xfrm_policy.c:618
      read of size 2 at addr ffff8801c8e92fe4 by task kworker/1:1/23 [..]
      Workqueue: events xfrm_hash_rebuild [..]
       __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428
       xfrm_hash_rebuild+0xdbe/0xf00 net/xfrm/xfrm_policy.c:618
       process_one_work+0xbbf/0x1b10 kernel/workqueue.c:2112
       worker_thread+0x223/0x1990 kernel/workqueue.c:2246 [..]
      
      The reproducer triggers:
      1016                 if (error) {
      1017                         list_move_tail(&walk->walk.all, &x->all);
      1018                         goto out;
      1019                 }
      
      in xfrm_policy_walk() via pfkey (it sets tiny rcv space, dump
      callback returns -ENOBUFS).
      
      In this case, *walk is located the pfkey socket struct, so this socket
      becomes visible in the global policy list.
      
      It looks like this is intentional -- phony walker has walk.dead set to 1
      and all other places skip such "policies".
      
      Ccing original authors of the two commits that seem to expose this
      issue (first patch missed ->dead check, second patch adds pfkey
      sockets to policies dumper list).
      
      Fixes: 880a6fab ("xfrm: configure policy hash table thresholds by netlink")
      Fixes: 12a169e7 ("ipsec: Put dumpers on the dump list")
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Timo Teras <timo.teras@iki.fi>
      Cc: Christophe Gouault <christophe.gouault@6wind.com>
      Reported-by: default avatarsyzbot <bot+c028095236fcb6f4348811565b75084c754dc729@syzkaller.appspotmail.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e754b4e
    • Sabrina Dubroca's avatar
      xfrm: fix rcu usage in xfrm_get_type_offload · e8370258
      Sabrina Dubroca authored
      commit 2f10a61c upstream.
      
      request_module can sleep, thus we cannot hold rcu_read_lock() while
      calling it. The function also jumps back and takes rcu_read_lock()
      again (in xfrm_state_get_afinfo()), resulting in an imbalance.
      
      This codepath is triggered whenever a new offloaded state is created.
      
      Fixes: ffdb5211 ("xfrm: Auto-load xfrm offload modules")
      Reported-by: syzbot+ca425f44816d749e8eb49755567a75ee48cf4a30@syzkaller.appspotmail.com
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e8370258
    • Florian Westphal's avatar
      xfrm: don't call xfrm_policy_cache_flush while holding spinlock · 85c31887
      Florian Westphal authored
      commit b1bdcb59 upstream.
      
      xfrm_policy_cache_flush can sleep, so it cannot be called while holding
      a spinlock.  We could release the lock first, but I don't see why we need
      to invoke this function here in first place, the packet path won't reuse
      an xdst entry unless its still valid.
      
      While at it, add an annotation to xfrm_policy_cache_flush, it would
      have probably caught this bug sooner.
      
      Fixes: ec30d78c ("xfrm: add xdst pcpu cache")
      Reported-by: syzbot+e149f7d1328c26f9c12f@syzkaller.appspotmail.com
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      85c31887
    • Steffen Klassert's avatar
      esp: Fix GRO when the headers not fully in the linear part of the skb. · 20194136
      Steffen Klassert authored
      commit 374d1b5a upstream.
      
      The GRO layer does not necessarily pull the complete headers
      into the linear part of the skb, a part may remain on the
      first page fragment. This can lead to a crash if we try to
      pull the headers, so make sure we have them on the linear
      part before pulling.
      
      Fixes: 7785bba2 ("esp: Add a software GRO codepath")
      Reported-by: syzbot+82bbd65569c49c6c0c4d@syzkaller.appspotmail.com
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20194136
    • Johannes Berg's avatar
      mac80211_hwsim: validate number of different channels · 447f1170
      Johannes Berg authored
      commit 51a1aaa6 upstream.
      
      When creating a new radio on the fly, hwsim allows this
      to be done with an arbitrary number of channels, but
      cfg80211 only supports a limited number of simultaneous
      channels, leading to a warning.
      
      Fix this by validating the number - this requires moving
      the define for the maximum out to a visible header file.
      
      Reported-by: syzbot+8dd9051ff19940290931@syzkaller.appspotmail.com
      Fixes: b59ec8dd ("mac80211_hwsim: fix number of channels in interface combinations")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      447f1170
    • Johannes Berg's avatar
      cfg80211: check dev_set_name() return value · b9e441e2
      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>
      b9e441e2
    • Daniel Borkmann's avatar
      bpf: mark dst unknown on inconsistent {s, u}bounds adjustments · ddf0936b
      Daniel Borkmann authored
      commit 6f16101e upstream.
      
      syzkaller generated a BPF proglet and triggered a warning with
      the following:
      
        0: (b7) r0 = 0
        1: (d5) if r0 s<= 0x0 goto pc+0
         R0=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        2: (1f) r0 -= r1
         R0=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        verifier internal error: known but bad sbounds
      
      What happens is that in the first insn, r0's min/max value
      are both 0 due to the immediate assignment, later in the jsle
      test the bounds are updated for the min value in the false
      path, meaning, they yield smin_val = 1, smax_val = 0, and when
      ctx pointer is subtracted from r0, verifier bails out with the
      internal error and throwing a WARN since smin_val != smax_val
      for the known constant.
      
      For min_val > max_val scenario it means that reg_set_min_max()
      and reg_set_min_max_inv() (which both refine existing bounds)
      demonstrated that such branch cannot be taken at runtime.
      
      In above scenario for the case where it will be taken, the
      existing [0, 0] bounds are kept intact. Meaning, the rejection
      is not due to a verifier internal error, and therefore the
      WARN() is not necessary either.
      
      We could just reject such cases in adjust_{ptr,scalar}_min_max_vals()
      when either known scalars have smin_val != smax_val or
      umin_val != umax_val or any scalar reg with bounds
      smin_val > smax_val or umin_val > umax_val. However, there
      may be a small risk of breakage of buggy programs, so handle
      this more gracefully and in adjust_{ptr,scalar}_min_max_vals()
      just taint the dst reg as unknown scalar when we see ops with
      such kind of src reg.
      
      Reported-by: syzbot+6d362cadd45dc0a12ba4@syzkaller.appspotmail.com
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ddf0936b
    • Tom Herbert's avatar
      kcm: Only allow TCP sockets to be attached to a KCM mux · 6c0b7120
      Tom Herbert authored
      commit 581e7226 upstream.
      
      TCP sockets for IPv4 and IPv6 that are not listeners or in closed
      stated are allowed to be attached to a KCM mux.
      
      Fixes: ab7ac4eb ("kcm: Kernel Connection Multiplexor module")
      Reported-by: syzbot+8865eaff7f9acd593945@syzkaller.appspotmail.com
      Signed-off-by: default avatarTom Herbert <tom@quantonium.net>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c0b7120
    • Tom Herbert's avatar
      kcm: Check if sk_user_data already set in kcm_attach · 44890e9f
      Tom Herbert authored
      commit e5571240 upstream.
      
      This is needed to prevent sk_user_data being overwritten.
      The check is done under the callback lock. This should prevent
      a socket from being attached twice to a KCM mux. It also prevents
      a socket from being attached for other use cases of sk_user_data
      as long as the other cases set sk_user_data under the lock.
      Followup work is needed to unify all the use cases of sk_user_data
      to use the same locking.
      
      Reported-by: syzbot+114b15f2be420a8886c3@syzkaller.appspotmail.com
      Fixes: ab7ac4eb ("kcm: Kernel Connection Multiplexor module")
      Signed-off-by: default avatarTom Herbert <tom@quantonium.net>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44890e9f
    • Jason Wang's avatar
      vhost: use mutex_lock_nested() in vhost_dev_lock_vqs() · ed25667f
      Jason Wang authored
      commit e9cb4239 upstream.
      
      We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
      hold mutexes of all virtqueues. This may confuse lockdep to report a
      possible deadlock because of trying to hold locks belong to same
      class. Switch to use mutex_lock_nested() to avoid false positive.
      
      Fixes: 6b1e6cc7 ("vhost: new device IOTLB API")
      Reported-by: syzbot+dbb7c1161485e61b0241@syzkaller.appspotmail.com
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed25667f
    • Takashi Iwai's avatar
      usb: core: Add a helper function to check the validity of EP type in URB · ebf7d035
      Takashi Iwai authored
      commit e901b987 upstream.
      
      This patch adds a new helper function to perform a sanity check of the
      given URB to see whether it contains a valid endpoint.  It's a light-
      weight version of what usb_submit_urb() does, but without the kernel
      warning followed by the stack trace, just returns an error code.
      
      Especially for a driver that doesn't parse the descriptor but fills
      the URB with the fixed endpoint (e.g. some quirks for non-compliant
      devices), this kind of check is preferable at the probe phase before
      actually submitting the urb.
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebf7d035
  2. 22 Feb, 2018 19 commits