1. 26 Feb, 2019 1 commit
  2. 25 Feb, 2019 2 commits
  3. 23 Feb, 2019 23 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.103 · c793fa33
      Greg Kroah-Hartman authored
      c793fa33
    • Eric Dumazet's avatar
      ax25: fix possible use-after-free · d283ed95
      Eric Dumazet authored
      commit 63530aba7826a0f8e129874df9c4d264f9db3f9e upstream.
      
      syzbot found that ax25 routes where not properly protected
      against concurrent use [1].
      
      In this particular report the bug happened while
      copying ax25->digipeat.
      
      Fix this problem by making sure we call ax25_get_route()
      while ax25_route_lock is held, so that no modification
      could happen while using the route.
      
      The current two ax25_get_route() callers do not sleep,
      so this change should be fine.
      
      Once we do that, ax25_get_route() no longer needs to
      grab a reference on the found route.
      
      [1]
      ax25_connect(): syz-executor0 uses autobind, please contact jreuter@yaina.de
      BUG: KASAN: use-after-free in memcpy include/linux/string.h:352 [inline]
      BUG: KASAN: use-after-free in kmemdup+0x42/0x60 mm/util.c:113
      Read of size 66 at addr ffff888066641a80 by task syz-executor2/531
      
      ax25_connect(): syz-executor0 uses autobind, please contact jreuter@yaina.de
      CPU: 1 PID: 531 Comm: syz-executor2 Not tainted 5.0.0-rc2+ #10
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       check_memory_region_inline mm/kasan/generic.c:185 [inline]
       check_memory_region+0x123/0x190 mm/kasan/generic.c:191
       memcpy+0x24/0x50 mm/kasan/common.c:130
       memcpy include/linux/string.h:352 [inline]
       kmemdup+0x42/0x60 mm/util.c:113
       kmemdup include/linux/string.h:425 [inline]
       ax25_rt_autobind+0x25d/0x750 net/ax25/ax25_route.c:424
       ax25_connect.cold+0x30/0xa4 net/ax25/af_ax25.c:1224
       __sys_connect+0x357/0x490 net/socket.c:1664
       __do_sys_connect net/socket.c:1675 [inline]
       __se_sys_connect net/socket.c:1672 [inline]
       __x64_sys_connect+0x73/0xb0 net/socket.c:1672
       do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x458099
      Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f870ee22c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458099
      RDX: 0000000000000048 RSI: 0000000020000080 RDI: 0000000000000005
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      ax25_connect(): syz-executor4 uses autobind, please contact jreuter@yaina.de
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f870ee236d4
      R13: 00000000004be48e R14: 00000000004ce9a8 R15: 00000000ffffffff
      
      Allocated by task 526:
       save_stack+0x45/0xd0 mm/kasan/common.c:73
       set_track mm/kasan/common.c:85 [inline]
       __kasan_kmalloc mm/kasan/common.c:496 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
      ax25_connect(): syz-executor5 uses autobind, please contact jreuter@yaina.de
       kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609
       kmalloc include/linux/slab.h:545 [inline]
       ax25_rt_add net/ax25/ax25_route.c:95 [inline]
       ax25_rt_ioctl+0x3b9/0x1270 net/ax25/ax25_route.c:233
       ax25_ioctl+0x322/0x10b0 net/ax25/af_ax25.c:1763
       sock_do_ioctl+0xe2/0x400 net/socket.c:950
       sock_ioctl+0x32f/0x6c0 net/socket.c:1074
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0x107b/0x17d0 fs/ioctl.c:696
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl fs/ioctl.c:718 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
       do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      ax25_connect(): syz-executor5 uses autobind, please contact jreuter@yaina.de
      Freed by task 550:
       save_stack+0x45/0xd0 mm/kasan/common.c:73
       set_track mm/kasan/common.c:85 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
       __cache_free mm/slab.c:3487 [inline]
       kfree+0xcf/0x230 mm/slab.c:3806
       ax25_rt_add net/ax25/ax25_route.c:92 [inline]
       ax25_rt_ioctl+0x304/0x1270 net/ax25/ax25_route.c:233
       ax25_ioctl+0x322/0x10b0 net/ax25/af_ax25.c:1763
       sock_do_ioctl+0xe2/0x400 net/socket.c:950
       sock_ioctl+0x32f/0x6c0 net/socket.c:1074
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0x107b/0x17d0 fs/ioctl.c:696
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl fs/ioctl.c:718 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
       do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff888066641a80
       which belongs to the cache kmalloc-96 of size 96
      The buggy address is located 0 bytes inside of
       96-byte region [ffff888066641a80, ffff888066641ae0)
      The buggy address belongs to the page:
      page:ffffea0001999040 count:1 mapcount:0 mapping:ffff88812c3f04c0 index:0x0
      flags: 0x1fffc0000000200(slab)
      ax25_connect(): syz-executor4 uses autobind, please contact jreuter@yaina.de
      raw: 01fffc0000000200 ffffea0001817948 ffffea0002341dc8 ffff88812c3f04c0
      raw: 0000000000000000 ffff888066641000 0000000100000020 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888066641980: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
       ffff888066641a00: 00 00 00 00 00 00 00 00 02 fc fc fc fc fc fc fc
      >ffff888066641a80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
                         ^
       ffff888066641b00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
       ffff888066641b80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d283ed95
    • Eric Dumazet's avatar
      mISDN: fix a race in dev_expire_timer() · d8eba3df
      Eric Dumazet authored
      commit bdcc5bc25548ef6b08e2e43937148f907c212292 upstream.
      
      Since mISDN_close() uses dev->pending to iterate over active
      timers, there is a chance that one timer got removed from the
      ->pending list in dev_expire_timer() but that the thread
      has not called yet wake_up_interruptible()
      
      So mISDN_close() could miss this and free dev before
      completion of at least one dev_expire_timer()
      
      syzbot was able to catch this race :
      
      BUG: KASAN: use-after-free in register_lock_class+0x140c/0x1bf0 kernel/locking/lockdep.c:827
      Write of size 8 at addr ffff88809fc18948 by task syz-executor1/24769
      
      CPU: 1 PID: 24769 Comm: syz-executor1 Not tainted 5.0.0-rc5 #60
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       __asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:140
       register_lock_class+0x140c/0x1bf0 kernel/locking/lockdep.c:827
       __lock_acquire+0x11f/0x4700 kernel/locking/lockdep.c:3224
       lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152
       __wake_up_common_lock+0xc7/0x190 kernel/sched/wait.c:120
       __wake_up+0xe/0x10 kernel/sched/wait.c:145
       dev_expire_timer+0xe4/0x3b0 drivers/isdn/mISDN/timerdev.c:174
       call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
      protocol 88fb is buggy, dev hsr_slave_0
      protocol 88fb is buggy, dev hsr_slave_1
       expire_timers kernel/time/timer.c:1362 [inline]
       __run_timers kernel/time/timer.c:1681 [inline]
       __run_timers kernel/time/timer.c:1649 [inline]
       run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
       __do_softirq+0x266/0x95a kernel/softirq.c:292
       invoke_softirq kernel/softirq.c:373 [inline]
       irq_exit+0x180/0x1d0 kernel/softirq.c:413
       exiting_irq arch/x86/include/asm/apic.h:536 [inline]
       smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
       </IRQ>
      RIP: 0010:__sanitizer_cov_trace_pc+0x26/0x50 kernel/kcov.c:101
      Code: 90 90 90 90 55 48 89 e5 48 8b 75 08 65 48 8b 04 25 40 ee 01 00 65 8b 15 98 12 92 7e 81 e2 00 01 1f 00 75 2b 8b 90 d8 12 00 00 <83> fa 02 75 20 48 8b 88 e0 12 00 00 8b 80 dc 12 00 00 48 8b 11 48
      RSP: 0018:ffff8880589b7a60 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
      RAX: ffff888087ce25c0 RBX: 0000000000000001 RCX: ffffffff818f8ca3
      RDX: 0000000000000000 RSI: ffffffff818f8b48 RDI: 0000000000000001
      RBP: ffff8880589b7a60 R08: ffff888087ce25c0 R09: ffffed1015d25bd0
      R10: ffffed1015d25bcf R11: ffff8880ae92de7b R12: ffffea0001ae4680
      R13: ffffea0001ae4688 R14: 0000000000000000 R15: ffffea0001b41648
       PageIdle include/linux/page-flags.h:398 [inline]
       page_is_idle include/linux/page_idle.h:29 [inline]
       mark_page_accessed+0x618/0x1140 mm/swap.c:398
       touch_buffer fs/buffer.c:59 [inline]
       __find_get_block+0x312/0xcc0 fs/buffer.c:1298
       sb_find_get_block include/linux/buffer_head.h:338 [inline]
       recently_deleted fs/ext4/ialloc.c:682 [inline]
       find_inode_bit.isra.0+0x202/0x510 fs/ext4/ialloc.c:722
       __ext4_new_inode+0x14ad/0x52c0 fs/ext4/ialloc.c:914
       ext4_symlink+0x3f8/0xbe0 fs/ext4/namei.c:3096
       vfs_symlink fs/namei.c:4126 [inline]
       vfs_symlink+0x378/0x5d0 fs/namei.c:4112
       do_symlinkat+0x22b/0x290 fs/namei.c:4153
       __do_sys_symlink fs/namei.c:4172 [inline]
       __se_sys_symlink fs/namei.c:4170 [inline]
       __x64_sys_symlink+0x59/0x80 fs/namei.c:4170
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457b67
      Code: 0f 1f 00 b8 5c 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 6d bb fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 58 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 4d bb fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fff045ce0f8 EFLAGS: 00000202 ORIG_RAX: 0000000000000058
      RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 0000000000457b67
      RDX: 00007fff045ce173 RSI: 00000000004bd63f RDI: 00007fff045ce160
      RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013
      R10: 0000000000000075 R11: 0000000000000202 R12: 0000000000000000
      R13: 0000000000000001 R14: 000000000000029b R15: 0000000000000001
      
      Allocated by task 24763:
       save_stack+0x45/0xd0 mm/kasan/common.c:73
       set_track mm/kasan/common.c:85 [inline]
       __kasan_kmalloc mm/kasan/common.c:496 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
       kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609
       kmalloc include/linux/slab.h:545 [inline]
       mISDN_open+0x9a/0x270 drivers/isdn/mISDN/timerdev.c:59
       misc_open+0x398/0x4c0 drivers/char/misc.c:141
       chrdev_open+0x247/0x6b0 fs/char_dev.c:417
       do_dentry_open+0x47d/0x1130 fs/open.c:771
       vfs_open+0xa0/0xd0 fs/open.c:880
       do_last fs/namei.c:3418 [inline]
       path_openat+0x10d7/0x4690 fs/namei.c:3534
       do_filp_open+0x1a1/0x280 fs/namei.c:3564
       do_sys_open+0x3fe/0x5d0 fs/open.c:1063
       __do_sys_openat fs/open.c:1090 [inline]
       __se_sys_openat fs/open.c:1084 [inline]
       __x64_sys_openat+0x9d/0x100 fs/open.c:1084
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 24762:
       save_stack+0x45/0xd0 mm/kasan/common.c:73
       set_track mm/kasan/common.c:85 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
       __cache_free mm/slab.c:3487 [inline]
       kfree+0xcf/0x230 mm/slab.c:3806
       mISDN_close+0x2a1/0x390 drivers/isdn/mISDN/timerdev.c:97
       __fput+0x2df/0x8d0 fs/file_table.c:278
       ____fput+0x16/0x20 fs/file_table.c:309
       task_work_run+0x14a/0x1c0 kernel/task_work.c:113
       tracehook_notify_resume include/linux/tracehook.h:188 [inline]
       exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166
       prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
       do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff88809fc18900
       which belongs to the cache kmalloc-192 of size 192
      The buggy address is located 72 bytes inside of
       192-byte region [ffff88809fc18900, ffff88809fc189c0)
      The buggy address belongs to the page:
      page:ffffea00027f0600 count:1 mapcount:0 mapping:ffff88812c3f0040 index:0xffff88809fc18000
      flags: 0x1fffc0000000200(slab)
      raw: 01fffc0000000200 ffffea000269f648 ffffea00029f7408 ffff88812c3f0040
      raw: ffff88809fc18000 ffff88809fc18000 000000010000000b 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88809fc18800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff88809fc18880: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88809fc18900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                    ^
       ffff88809fc18980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff88809fc18a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8eba3df
    • Eric Dumazet's avatar
      net/x25: do not hold the cpu too long in x25_new_lci() · c01e01ad
      Eric Dumazet authored
      commit cf657d22ee1f0e887326a92169f2e28dc932fd10 upstream.
      
      Due to quadratic behavior of x25_new_lci(), syzbot was able
      to trigger an rcu stall.
      
      Fix this by not blocking BH for the whole duration of
      the function, and inserting a reschedule point when possible.
      
      If we care enough, using a bitmap could get rid of the quadratic
      behavior.
      
      syzbot report :
      
      rcu: INFO: rcu_preempt self-detected stall on CPU
      rcu:    0-...!: (10500 ticks this GP) idle=4fa/1/0x4000000000000002 softirq=283376/283376 fqs=0
      rcu:     (t=10501 jiffies g=383105 q=136)
      rcu: rcu_preempt kthread starved for 10502 jiffies! g383105 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
      rcu: RCU grace-period kthread stack dump:
      rcu_preempt     I28928    10      2 0x80000000
      Call Trace:
       context_switch kernel/sched/core.c:2844 [inline]
       __schedule+0x817/0x1cc0 kernel/sched/core.c:3485
       schedule+0x92/0x180 kernel/sched/core.c:3529
       schedule_timeout+0x4db/0xfd0 kernel/time/timer.c:1803
       rcu_gp_fqs_loop kernel/rcu/tree.c:1948 [inline]
       rcu_gp_kthread+0x956/0x17a0 kernel/rcu/tree.c:2105
       kthread+0x357/0x430 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      NMI backtrace for cpu 0
      CPU: 0 PID: 8759 Comm: syz-executor2 Not tainted 5.0.0-rc4+ #51
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
       nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
       arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
       trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
       rcu_dump_cpu_stacks+0x183/0x1cf kernel/rcu/tree.c:1211
       print_cpu_stall kernel/rcu/tree.c:1348 [inline]
       check_cpu_stall kernel/rcu/tree.c:1422 [inline]
       rcu_pending kernel/rcu/tree.c:3018 [inline]
       rcu_check_callbacks.cold+0x500/0xa4a kernel/rcu/tree.c:2521
       update_process_times+0x32/0x80 kernel/time/timer.c:1635
       tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:161
       tick_sched_timer+0x47/0x130 kernel/time/tick-sched.c:1271
       __run_hrtimer kernel/time/hrtimer.c:1389 [inline]
       __hrtimer_run_queues+0x33e/0xde0 kernel/time/hrtimer.c:1451
       hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
       local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1035 [inline]
       smp_apic_timer_interrupt+0x120/0x570 arch/x86/kernel/apic/apic.c:1060
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
       </IRQ>
      RIP: 0010:__read_once_size include/linux/compiler.h:193 [inline]
      RIP: 0010:queued_write_lock_slowpath+0x13e/0x290 kernel/locking/qrwlock.c:86
      Code: 00 00 fc ff df 4c 8d 2c 01 41 83 c7 03 41 0f b6 45 00 41 38 c7 7c 08 84 c0 0f 85 0c 01 00 00 8b 03 3d 00 01 00 00 74 1a f3 90 <41> 0f b6 55 00 41 38 d7 7c eb 84 d2 74 e7 48 89 df e8 6c 0f 4f 00
      RSP: 0018:ffff88805f117bd8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
      RAX: 0000000000000300 RBX: ffffffff89413ba0 RCX: 1ffffffff1282774
      RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff89413ba0
      RBP: ffff88805f117c70 R08: 1ffffffff1282774 R09: fffffbfff1282775
      R10: fffffbfff1282774 R11: ffffffff89413ba3 R12: 00000000000000ff
      R13: fffffbfff1282774 R14: 1ffff1100be22f7d R15: 0000000000000003
       queued_write_lock include/asm-generic/qrwlock.h:104 [inline]
       do_raw_write_lock+0x1d6/0x290 kernel/locking/spinlock_debug.c:203
       __raw_write_lock_bh include/linux/rwlock_api_smp.h:204 [inline]
       _raw_write_lock_bh+0x3b/0x50 kernel/locking/spinlock.c:312
       x25_insert_socket+0x21/0xe0 net/x25/af_x25.c:267
       x25_bind+0x273/0x340 net/x25/af_x25.c:705
       __sys_bind+0x23f/0x290 net/socket.c:1505
       __do_sys_bind net/socket.c:1516 [inline]
       __se_sys_bind net/socket.c:1514 [inline]
       __x64_sys_bind+0x73/0xb0 net/socket.c:1514
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457e39
      Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fafccd0dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
      RDX: 0000000000000012 RSI: 0000000020000240 RDI: 0000000000000004
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fafccd0e6d4
      R13: 00000000004bdf8b R14: 00000000004ce4b8 R15: 00000000ffffffff
      Sending NMI from CPU 0 to CPUs 1:
      NMI backtrace for cpu 1
      CPU: 1 PID: 8752 Comm: syz-executor4 Not tainted 5.0.0-rc4+ #51
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__x25_find_socket+0x78/0x120 net/x25/af_x25.c:328
      Code: 89 f8 48 c1 e8 03 80 3c 18 00 0f 85 a6 00 00 00 4d 8b 64 24 68 4d 85 e4 74 7f e8 03 97 3d fb 49 83 ec 68 74 74 e8 f8 96 3d fb <49> 8d bc 24 88 04 00 00 48 89 f8 48 c1 e8 03 0f b6 04 18 84 c0 74
      RSP: 0018:ffff8880639efc58 EFLAGS: 00000246
      RAX: 0000000000040000 RBX: dffffc0000000000 RCX: ffffc9000e677000
      RDX: 0000000000040000 RSI: ffffffff863244b8 RDI: ffff88806a764628
      RBP: ffff8880639efc80 R08: ffff8880a80d05c0 R09: fffffbfff1282775
      R10: fffffbfff1282774 R11: ffffffff89413ba3 R12: ffff88806a7645c0
      R13: 0000000000000001 R14: ffff88809f29ac00 R15: 0000000000000000
      FS:  00007fe8d0c58700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b32823000 CR3: 00000000672eb000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       x25_new_lci net/x25/af_x25.c:357 [inline]
       x25_connect+0x374/0xdf0 net/x25/af_x25.c:786
       __sys_connect+0x266/0x330 net/socket.c:1686
       __do_sys_connect net/socket.c:1697 [inline]
       __se_sys_connect net/socket.c:1694 [inline]
       __x64_sys_connect+0x73/0xb0 net/socket.c:1694
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457e39
      Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fe8d0c57c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
      RDX: 0000000000000012 RSI: 0000000020000200 RDI: 0000000000000004
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe8d0c586d4
      R13: 00000000004be378 R14: 00000000004ceb00 R15: 00000000ffffffff
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Andrew Hendry <andrew.hendry@gmail.com>
      Cc: linux-x25@vger.kernel.org
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c01e01ad
    • Scott Mayhew's avatar
      sunrpc: fix 4 more call sites that were using stack memory with a scatterlist · aa1e52cb
      Scott Mayhew authored
      commit e7afe6c1d486b516ed586dcc10b3e7e3e85a9c2b upstream.
      
      While trying to reproduce a reported kernel panic on arm64, I discovered
      that AUTH_GSS basically doesn't work at all with older enctypes on arm64
      systems with CONFIG_VMAP_STACK enabled.  It turns out there still a few
      places using stack memory with scatterlists, causing krb5_encrypt() and
      krb5_decrypt() to produce incorrect results (or a BUG if CONFIG_DEBUG_SG
      is enabled).
      
      Tested with cthon on v4.0/v4.1/v4.2 with krb5/krb5i/krb5p using
      des3-cbc-sha1 and arcfour-hmac-md5.
      Signed-off-by: 's avatarScott Mayhew <smayhew@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa1e52cb
    • Eric Dumazet's avatar
      tcp: clear icsk_backoff in tcp_write_queue_purge() · 3a493b76
      Eric Dumazet authored
      [ Upstream commit 04c03114be82194d4a4858d41dba8e286ad1787c ]
      
      soukjin bae reported a crash in tcp_v4_err() handling
      ICMP_DEST_UNREACH after tcp_write_queue_head(sk)
      returned a NULL pointer.
      
      Current logic should have prevented this :
      
        if (seq != tp->snd_una  || !icsk->icsk_retransmits ||
            !icsk->icsk_backoff || fastopen)
            break;
      
      Problem is the write queue might have been purged
      and icsk_backoff has not been cleared.
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsoukjin bae <soukjin.bae@samsung.com>
      Acked-by: 's avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a493b76
    • Alexander Duyck's avatar
      net: Do not allocate page fragments that are not skb aligned · 859838ff
      Alexander Duyck authored
      [ Upstream commit 3bed3cc4156eedf652b4df72bdb35d4f1a2a739d ]
      
      This patch addresses the fact that there are drivers, specifically tun,
      that will call into the network page fragment allocators with buffer sizes
      that are not cache aligned. Doing this could result in data alignment
      and DMA performance issues as these fragment pools are also shared with the
      skb allocator and any other devices that will use napi_alloc_frags or
      netdev_alloc_frags.
      
      Fixes: ffde7328 ("net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag")
      Reported-by: 's avatarJann Horn <jannh@google.com>
      Signed-off-by: 's avatarAlexander Duyck <alexander.h.duyck@linux.intel.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      859838ff
    • Eric Dumazet's avatar
      tcp: tcp_v4_err() should be more careful · 55103aa3
      Eric Dumazet authored
      [ Upstream commit 2c4cc9712364c051b1de2d175d5fbea6be948ebf ]
      
      ICMP handlers are not very often stressed, we should
      make them more resilient to bugs that might surface in
      the future.
      
      If there is no packet in retransmit queue, we should
      avoid a NULL deref.
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsoukjin bae <soukjin.bae@samsung.com>
      Acked-by: 's avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: 's avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      55103aa3
    • David S. Miller's avatar
      net: Add header for usage of fls64() · 8565b7fb
      David S. Miller authored
      [ Upstream commit 8681ef1f3d295bd3600315325f3b3396d76d02f6 ]
      
      Fixes: 3b89ea9c5902 ("net: Fix for_each_netdev_feature on Big endian")
      Suggested-by: 's avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8565b7fb
    • Jason Wang's avatar
      vhost: correctly check the return value of translate_desc() in log_used() · d5a74d2b
      Jason Wang authored
      [ Upstream commit 816db7663565cd23f74ed3d5c9240522e3fb0dda ]
      
      When fail, translate_desc() returns negative value, otherwise the
      number of iovs. So we should fail when the return value is negative
      instead of a blindly check against zero.
      
      Detected by CoverityScan, CID# 1442593:  Control flow issues  (DEADCODE)
      
      Fixes: cc5e71075947 ("vhost: log dirty page correctly")
      Acked-by: 's avatarMichael S. Tsirkin <mst@redhat.com>
      Reported-by: 's avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: 's avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5a74d2b
    • Kai-Heng Feng's avatar
      sky2: Increase D3 delay again · 546b8f66
      Kai-Heng Feng authored
      [ Upstream commit 1765f5dcd00963e33f1b8a4e0f34061fbc0e2f7f ]
      
      Another platform requires even longer delay to make the device work
      correctly after S3.
      
      So increase the delay to 300ms.
      
      BugLink: https://bugs.launchpad.net/bugs/1798921Signed-off-by: 's avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      546b8f66
    • Alexandre Torgue's avatar
      net: stmmac: handle endianness in dwmac4_get_timestamp · b690bf8f
      Alexandre Torgue authored
      [ Upstream commit 224babd62d6f19581757a6d8bae3bf9501fc10de ]
      
      GMAC IP is little-endian and used on several kind of CPU (big or little
      endian). Main callbacks functions of the stmmac drivers take care about
      it. It was not the case for dwmac4_get_timestamp function.
      
      Fixes: ba1ffd74 ("stmmac: fix PTP support for GMAC4")
      Signed-off-by: 's avatarAlexandre Torgue <alexandre.torgue@st.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b690bf8f
    • Jose Abreu's avatar
      net: stmmac: Fix a race in EEE enable callback · c15b7add
      Jose Abreu authored
      [ Upstream commit 8a7493e58ad688eb23b81e45461c5d314f4402f1 ]
      
      We are saving the status of EEE even before we try to enable it. This
      leads to a race with XMIT function that tries to arm EEE timer before we
      set it up.
      
      Fix this by only saving the EEE parameters after all operations are
      performed with success.
      Signed-off-by: 's avatarJose Abreu <joabreu@synopsys.com>
      Fixes: d765955d ("stmmac: add the Energy Efficient Ethernet support")
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c15b7add
    • Paul Kocialkowski's avatar
      net: phy: xgmiitorgmii: Support generic PHY status read · 7193b3d0
      Paul Kocialkowski authored
      [ Upstream commit 197f9ab7f08ce4b9ece662f747c3991b2f0fbb57 ]
      
      Some PHY drivers like the generic one do not provide a read_status
      callback on their own but rely on genphy_read_status being called
      directly.
      
      With the current code, this results in a NULL function pointer call.
      Call genphy_read_status instead when there is no specific callback.
      
      Fixes: f411a616 ("net: phy: Add gmiitorgmii converter support")
      Signed-off-by: 's avatarPaul Kocialkowski <paul.kocialkowski@bootlin.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7193b3d0
    • Hauke Mehrtens's avatar
      net: Fix for_each_netdev_feature on Big endian · 5d3d720d
      Hauke Mehrtens authored
      [ Upstream commit 3b89ea9c5902acccdbbdec307c85edd1bf52515e ]
      
      The features attribute is of type u64 and stored in the native endianes on
      the system. The for_each_set_bit() macro takes a pointer to a 32 bit array
      and goes over the bits in this area. On little Endian systems this also
      works with an u64 as the most significant bit is on the highest address,
      but on big endian the words are swapped. When we expect bit 15 here we get
      bit 47 (15 + 32).
      
      This patch converts it more or less to its own for_each_set_bit()
      implementation which works on 64 bit integers directly. This is then
      completely in host endianness and should work like expected.
      
      Fixes: fd867d51 ("net/core: generic support for disabling netdev features down stack")
      Signed-off-by: 's avatarHauke Mehrtens <hauke.mehrtens@intel.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d3d720d
    • Mao Wenan's avatar
      net: crypto set sk to NULL when af_alg_release. · 6e4c01ee
      Mao Wenan authored
      [ Upstream commit 9060cb719e61b685ec0102574e10337fa5f445ea ]
      
      KASAN has found use-after-free in sockfs_setattr.
      The existed commit 6d8c50dcb029 ("socket: close race condition between sock_close()
      and sockfs_setattr()") is to fix this simillar issue, but it seems to ignore
      that crypto module forgets to set the sk to NULL after af_alg_release.
      
      KASAN report details as below:
      BUG: KASAN: use-after-free in sockfs_setattr+0x120/0x150
      Write of size 4 at addr ffff88837b956128 by task syz-executor0/4186
      
      CPU: 2 PID: 4186 Comm: syz-executor0 Not tainted xxx + #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       dump_stack+0xca/0x13e
       print_address_description+0x79/0x330
       ? vprintk_func+0x5e/0xf0
       kasan_report+0x18a/0x2e0
       ? sockfs_setattr+0x120/0x150
       sockfs_setattr+0x120/0x150
       ? sock_register+0x2d0/0x2d0
       notify_change+0x90c/0xd40
       ? chown_common+0x2ef/0x510
       chown_common+0x2ef/0x510
       ? chmod_common+0x3b0/0x3b0
       ? __lock_is_held+0xbc/0x160
       ? __sb_start_write+0x13d/0x2b0
       ? __mnt_want_write+0x19a/0x250
       do_fchownat+0x15c/0x190
       ? __ia32_sys_chmod+0x80/0x80
       ? trace_hardirqs_on_thunk+0x1a/0x1c
       __x64_sys_fchownat+0xbf/0x160
       ? lockdep_hardirqs_on+0x39a/0x5e0
       do_syscall_64+0xc8/0x580
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462589
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89
      f7 48 89 d6 48 89
      ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3
      48 c7 c1 bc ff ff
      ff f7 d8 64 89 01 48
      RSP: 002b:00007fb4b2c83c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000104
      RAX: ffffffffffffffda RBX: 000000000072bfa0 RCX: 0000000000462589
      RDX: 0000000000000000 RSI: 00000000200000c0 RDI: 0000000000000007
      RBP: 0000000000000005 R08: 0000000000001000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb4b2c846bc
      R13: 00000000004bc733 R14: 00000000006f5138 R15: 00000000ffffffff
      
      Allocated by task 4185:
       kasan_kmalloc+0xa0/0xd0
       __kmalloc+0x14a/0x350
       sk_prot_alloc+0xf6/0x290
       sk_alloc+0x3d/0xc00
       af_alg_accept+0x9e/0x670
       hash_accept+0x4a3/0x650
       __sys_accept4+0x306/0x5c0
       __x64_sys_accept4+0x98/0x100
       do_syscall_64+0xc8/0x580
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 4184:
       __kasan_slab_free+0x12e/0x180
       kfree+0xeb/0x2f0
       __sk_destruct+0x4e6/0x6a0
       sk_destruct+0x48/0x70
       __sk_free+0xa9/0x270
       sk_free+0x2a/0x30
       af_alg_release+0x5c/0x70
       __sock_release+0xd3/0x280
       sock_close+0x1a/0x20
       __fput+0x27f/0x7f0
       task_work_run+0x136/0x1b0
       exit_to_usermode_loop+0x1a7/0x1d0
       do_syscall_64+0x461/0x580
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Syzkaller reproducer:
      r0 = perf_event_open(&(0x7f0000000000)={0x0, 0x70, 0x0, 0x0, 0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, @perf_config_ext}, 0x0, 0x0,
      0xffffffffffffffff, 0x0)
      r1 = socket$alg(0x26, 0x5, 0x0)
      getrusage(0x0, 0x0)
      bind(r1, &(0x7f00000001c0)=@alg={0x26, 'hash\x00', 0x0, 0x0,
      'sha256-ssse3\x00'}, 0x80)
      r2 = accept(r1, 0x0, 0x0)
      r3 = accept4$unix(r2, 0x0, 0x0, 0x0)
      r4 = dup3(r3, r0, 0x0)
      fchownat(r4, &(0x7f00000000c0)='\x00', 0x0, 0x0, 0x1000)
      
      Fixes: 6d8c50dcb029 ("socket: close race condition between sock_close() and sockfs_setattr()")
      Signed-off-by: 's avatarMao Wenan <maowenan@huawei.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e4c01ee
    • Petr Machata's avatar
      mlxsw: __mlxsw_sp_port_headroom_set(): Fix a use of local variable · 052d0925
      Petr Machata authored
      [ Upstream commit 289460404f6947ef1c38e67d680be9a84161250b ]
      
      The function-local variable "delay" enters the loop interpreted as delay
      in bits. However, inside the loop it gets overwritten by the result of
      mlxsw_sp_pg_buf_delay_get(), and thus leaves the loop as quantity in
      cells. Thus on second and further loop iterations, the headroom for a
      given priority is configured with a wrong size.
      
      Fix by introducing a loop-local variable, delay_cells. Rename thres to
      thres_cells for consistency.
      
      Fixes: f417f04d ("mlxsw: spectrum: Refactor port buffer configuration")
      Signed-off-by: 's avatarPetr Machata <petrm@mellanox.com>
      Acked-by: 's avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: 's avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      052d0925
    • Wei Yongjun's avatar
      hwmon: (lm80) Fix missing unlock on error in set_fan_div() · 48dc41af
      Wei Yongjun authored
      [ Upstream commit 07bd14ccc3049f9c0147a91a4227a571f981601a ]
      
      Add the missing unlock before return from function set_fan_div()
      in the error handling case.
      
      Fixes: c9c63915519b ("hwmon: (lm80) fix a missing check of the status of SMBus read")
      Signed-off-by: 's avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: 's avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      48dc41af
    • Eric Dumazet's avatar
      vxlan: test dev->flags & IFF_UP before calling netif_rx() · 58cdc594
      Eric Dumazet authored
      [ Upstream commit 4179cb5a4c924cd233eaadd081882425bc98f44e ]
      
      netif_rx() must be called under a strict contract.
      
      At device dismantle phase, core networking clears IFF_UP
      and flush_all_backlogs() is called after rcu grace period
      to make sure no incoming packet might be in a cpu backlog
      and still referencing the device.
      
      Most drivers call netif_rx() from their interrupt handler,
      and since the interrupts are disabled at device dismantle,
      netif_rx() does not have to check dev->flags & IFF_UP
      
      Virtual drivers do not have this guarantee, and must
      therefore make the check themselves.
      
      Otherwise we risk use-after-free and/or crashes.
      
      Note this patch also fixes a small issue that came
      with commit ce6502a8 ("vxlan: fix a use after free
      in vxlan_encap_bypass"), since the dev->stats.rx_dropped
      change was done on the wrong device.
      
      Fixes: d342894c ("vxlan: virtual extensible lan")
      Fixes: ce6502a8 ("vxlan: fix a use after free in vxlan_encap_bypass")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: Petr Machata <petrm@mellanox.com>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Cc: Stefano Brivio <sbrivio@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      58cdc594
    • Paolo Abeni's avatar
      vsock: cope with memory allocation failure at socket creation time · 28beec65
      Paolo Abeni authored
      [ Upstream commit 225d9464268599a5b4d094d02ec17808e44c7553 ]
      
      In the unlikely event that the kmalloc call in vmci_transport_socket_init()
      fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
      and oopsing.
      
      This change addresses the above explicitly checking for zero vmci_trans()
      at destruction time.
      Reported-by: 's avatarXiumei Mu <xmu@redhat.com>
      Fixes: d021c344 ("VSOCK: Introduce VM Sockets")
      Signed-off-by: 's avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: 's avatarStefano Garzarella <sgarzare@redhat.com>
      Reviewed-by: 's avatarJorgen Hansen <jhansen@vmware.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      28beec65
    • Lorenzo Bianconi's avatar
      net: ipv4: use a dedicated counter for icmp_v4 redirect packets · 4e4d02b9
      Lorenzo Bianconi authored
      [ Upstream commit c09551c6ff7fe16a79a42133bcecba5fc2fc3291 ]
      
      According to the algorithm described in the comment block at the
      beginning of ip_rt_send_redirect, the host should try to send
      'ip_rt_redirect_number' ICMP redirect packets with an exponential
      backoff and then stop sending them at all assuming that the destination
      ignores redirects.
      If the device has previously sent some ICMP error packets that are
      rate-limited (e.g TTL expired) and continues to receive traffic,
      the redirect packets will never be transmitted. This happens since
      peer->rate_tokens will be typically greater than 'ip_rt_redirect_number'
      and so it will never be reset even if the redirect silence timeout
      (ip_rt_redirect_silence) has elapsed without receiving any packet
      requiring redirects.
      
      Fix it by using a dedicated counter for the number of ICMP redirect
      packets that has been sent by the host
      
      I have not been able to identify a given commit that introduced the
      issue since ip_rt_send_redirect implements the same rate-limiting
      algorithm from commit 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: 's avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      4e4d02b9
    • Zhiqiang Liu's avatar
      net: fix IPv6 prefix route residue · 3aafc445
      Zhiqiang Liu authored
      [ Upstream commit e75913c93f7cd5f338ab373c34c93a655bd309cb ]
      
      Follow those steps:
       # ip addr add 2001:123::1/32 dev eth0
       # ip addr add 2001:123:456::2/64 dev eth0
       # ip addr del 2001:123::1/32 dev eth0
       # ip addr del 2001:123:456::2/64 dev eth0
      and then prefix route of 2001:123::1/32 will still exist.
      
      This is because ipv6_prefix_equal in check_cleanup_prefix_route
      func does not check whether two IPv6 addresses have the same
      prefix length. If the prefix of one address starts with another
      shorter address prefix, even though their prefix lengths are
      different, the return value of ipv6_prefix_equal is true.
      
      Here I add a check of whether two addresses have the same prefix
      to decide whether their prefixes are equal.
      
      Fixes: 5b84efec ("ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE")
      Signed-off-by: 's avatarZhiqiang Liu <liuzhiqiang26@huawei.com>
      Reported-by: 's avatarWenhao Zhang <zhangwenhao8@huawei.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      3aafc445
    • John David Anglin's avatar
      dsa: mv88e6xxx: Ensure all pending interrupts are handled prior to exit · 1b18aad1
      John David Anglin authored
      [ Upstream commit 7c0db24cc431e2196d98a5d5ddaa9088e2fcbfe5 ]
      
      The GPIO interrupt controller on the espressobin board only supports edge interrupts.
      If one enables the use of hardware interrupts in the device tree for the 88E6341, it is
      possible to miss an edge.  When this happens, the INTn pin on the Marvell switch is
      stuck low and no further interrupts occur.
      
      I found after adding debug statements to mv88e6xxx_g1_irq_thread_work() that there is
      a race in handling device interrupts (e.g. PHY link interrupts).  Some interrupts are
      directly cleared by reading the Global 1 status register.  However, the device interrupt
      flag, for example, is not cleared until all the unmasked SERDES and PHY ports are serviced.
      This is done by reading the relevant SERDES and PHY status register.
      
      The code only services interrupts whose status bit is set at the time of reading its status
      register.  If an interrupt event occurs after its status is read and before all interrupts
      are serviced, then this event will not be serviced and the INTn output pin will remain low.
      
      This is not a problem with polling or level interrupts since the handler will be called
      again to process the event.  However, it's a big problem when using level interrupts.
      
      The fix presented here is to add a loop around the code servicing switch interrupts.  If
      any pending interrupts remain after the current set has been handled, we loop and process
      the new set.  If there are no pending interrupts after servicing, we are sure that INTn has
      gone high and we will get an edge when a new event occurs.
      
      Tested on espressobin board.
      
      Fixes: dc30c35b ("net: dsa: mv88e6xxx: Implement interrupt support.")
      Signed-off-by: 's avatarJohn David Anglin <dave.anglin@bell.net>
      Tested-by: 's avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      1b18aad1
  4. 20 Feb, 2019 14 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.102 · 5461ace2
      Greg Kroah-Hartman authored
      5461ace2
    • Hauke Mehrtens's avatar
      uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define · ae4199db
      Hauke Mehrtens authored
      commit da360299b6734135a5f66d7db458dcc7801c826a upstream.
      
      This fixes a compile problem of some user space applications by not
      including linux/libc-compat.h in uapi/if_ether.h.
      
      linux/libc-compat.h checks which "features" the header files, included
      from the libc, provide to make the Linux kernel uapi header files only
      provide no conflicting structures and enums. If a user application mixes
      kernel headers and libc headers it could happen that linux/libc-compat.h
      gets included too early where not all other libc headers are included
      yet. Then the linux/libc-compat.h would not prevent all the
      redefinitions and we run into compile problems.
      This patch removes the include of linux/libc-compat.h from
      uapi/if_ether.h to fix the recently introduced case, but not all as this
      is more or less impossible.
      
      It is no problem to do the check directly in the if_ether.h file and not
      in libc-compat.h as this does not need any fancy glibc header detection
      as glibc never provided struct ethhdr and should define
      __UAPI_DEF_ETHHDR by them self when they will provide this.
      
      The following test program did not compile correctly any more:
      
      #include <linux/if_ether.h>
      #include <netinet/in.h>
      #include <linux/in.h>
      
      int main(void)
      {
      	return 0;
      }
      
      Fixes: 6926e041a892 ("uapi/if_ether.h: prevent redefinition of struct ethhdr")
      Reported-by: 's avatarGuillaume Nault <g.nault@alphalink.fr>
      Cc: <stable@vger.kernel.org> # 4.15
      Signed-off-by: 's avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae4199db
    • Christian Lamparter's avatar
      pinctrl: msm: fix gpio-hog related boot issues · 38ffd6c9
      Christian Lamparter authored
      commit a86caa9ba5d70696ceb35d1d39caa20d8b641387 upstream.
      
      Sven Eckelmann reported an issue with the current IPQ4019 pinctrl.
      Setting up any gpio-hog in the device-tree for his device would
      "kill the bootup completely":
      
      | [    0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
      | [    0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferring probe
      | [    1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517
      | [    1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register
      | [    1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip
      | [    1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
      | [    1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferri
      
      This was also verified on a RT-AC58U (IPQ4018) which would
      no longer boot, if a gpio-hog was specified. (Tried forcing
      the USB LED PIN (GPIO0) to high.).
      
      The problem is that Pinctrl+GPIO registration is currently
      peformed in the following order in pinctrl-msm.c:
      	1. pinctrl_register()
      	2. gpiochip_add()
      	3. gpiochip_add_pin_range()
      
      The actual error code -517 == -EPROBE_DEFER is coming from
      pinctrl_get_device_gpio_range(), which is called through:
              gpiochip_add
                  of_gpiochip_add
                      of_gpiochip_scan_gpios
                          gpiod_hog
                              gpiochip_request_own_desc
                                  __gpiod_request
                                      chip->request
                                          gpiochip_generic_request
                                             pinctrl_gpio_request
                                                pinctrl_get_device_gpio_range
      
      pinctrl_get_device_gpio_range() is unable to find any valid
      pin ranges, since nothing has been added to the pinctrldev_list yet.
      so the range can't be found, and the operation fails with -EPROBE_DEFER.
      
      This patch fixes the issue by adding the "gpio-ranges" property to
      the pinctrl device node of all upstream Qcom SoC. The pin ranges are
      then added by the gpio core.
      
      In order to remain compatible with older, existing DTs (and ACPI)
      a check for the "gpio-ranges" property has been added to
      msm_gpio_init(). This prevents the driver of adding the same entry
      to the pinctrldev_list twice.
      Reported-by: 's avatarSven Eckelmann <sven.eckelmann@openmesh.com>
      Tested-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [ipq4019]
      Reviewed-by: 's avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Signed-off-by: 's avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: 's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: 's avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38ffd6c9
    • Thomas Gleixner's avatar
      futex: Cure exit race · 16de7ded
      Thomas Gleixner authored
      commit da791a667536bf8322042e38ca85d55a78d3c273 upstream.
      
      Stefan reported, that the glibc tst-robustpi4 test case fails
      occasionally. That case creates the following race between
      sys_exit() and sys_futex_lock_pi():
      
       CPU0				CPU1
      
       sys_exit()			sys_futex()
        do_exit()			 futex_lock_pi()
         exit_signals(tsk)		  No waiters:
          tsk->flags |= PF_EXITING;	  *uaddr == 0x00000PID
        mm_release(tsk)		  Set waiter bit
         exit_robust_list(tsk) {	  *uaddr = 0x80000PID;
            Set owner died		  attach_to_pi_owner() {
          *uaddr = 0xC0000000;	   tsk = get_task(PID);
         }				   if (!tsk->flags & PF_EXITING) {
        ...				     attach();
        tsk->flags |= PF_EXITPIDONE;	   } else {
      				     if (!(tsk->flags & PF_EXITPIDONE))
      				       return -EAGAIN;
      				     return -ESRCH; <--- FAIL
      				   }
      
      ESRCH is returned all the way to user space, which triggers the glibc test
      case assert. Returning ESRCH unconditionally is wrong here because the user
      space value has been changed by the exiting task to 0xC0000000, i.e. the
      FUTEX_OWNER_DIED bit is set and the futex PID value has been cleared. This
      is a valid state and the kernel has to handle it, i.e. taking the futex.
      
      Cure it by rereading the user space value when PF_EXITING and PF_EXITPIDONE
      is set in the task which 'owns' the futex. If the value has changed, let
      the kernel retry the operation, which includes all regular sanity checks
      and correctly handles the FUTEX_OWNER_DIED case.
      
      If it hasn't changed, then return ESRCH as there is no way to distinguish
      this case from malfunctioning user space. This happens when the exiting
      task did not have a robust list, the robust list was corrupted or the user
      space value in the futex was simply bogus.
      Reported-by: 's avatarStefan Liebler <stli@linux.ibm.com>
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: 's avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Sasha Levin <sashal@kernel.org>
      Cc: stable@vger.kernel.org
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200467
      Link: https://lkml.kernel.org/r/20181210152311.986181245@linutronix.deSigned-off-by: 's avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16de7ded
    • Pavankumar Kondeti's avatar
      sched, trace: Fix prev_state output in sched_switch tracepoint · e1e5fa73
      Pavankumar Kondeti authored
      commit 3054426dc68e5d63aa6a6e9b91ac4ec78e3f3805 upstream.
      
      commit 3f5fe9fef5b2 ("sched/debug: Fix task state recording/printout")
      tried to fix the problem introduced by a previous commit efb40f58
      ("sched/tracing: Fix trace_sched_switch task-state printing"). However
      the prev_state output in sched_switch is still broken.
      
      task_state_index() uses fls() which considers the LSB as 1. Left
      shifting 1 by this value gives an incorrect mapping to the task state.
      Fix this by decrementing the value returned by __get_task_state()
      before shifting.
      
      Link: http://lkml.kernel.org/r/1540882473-1103-1-git-send-email-pkondeti@codeaurora.org
      
      Cc: stable@vger.kernel.org
      Fixes: 3f5fe9fef5b2 ("sched/debug: Fix task state recording/printout")
      Signed-off-by: 's avatarPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: 's avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: 's avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1e5fa73
    • Joonas Lahtinen's avatar
      drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set · 36c495e9
      Joonas Lahtinen authored
      commit 2e7bd10e05afb866b5fb13eda25095c35d7a27cc upstream.
      
      Make sure the underlying VMA in the process address space is the
      same as it was during vm_mmap to avoid applying WC to wrong VMA.
      
      A more long-term solution would be to have vm_mmap_locked variant
      in linux/mmap.h for when caller wants to hold mmap_sem for an
      extended duration.
      
      v2:
      - Refactor the compare function
      
      Fixes: 1816f923 ("drm/i915: Support creation of unbound wc user mappings for objects")
      Reported-by: 's avatarAdam Zabrocki <adamza@microsoft.com>
      Suggested-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v4.0+
      Cc: Akash Goel <akash.goel@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Adam Zabrocki <adamza@microsoft.com>
      Reviewed-by: 's avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1
      Link: https://patchwork.freedesktop.org/patch/msgid/20190207085454.10598-1-joonas.lahtinen@linux.intel.com
      (cherry picked from commit 5c4604e757ba9b193b09768d75a7d2105a5b883f)
      Signed-off-by: 's avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36c495e9
    • Nikos Tsironis's avatar
      dm thin: fix bug where bio that overwrites thin block ignores FUA · 9998b44f
      Nikos Tsironis authored
      commit 4ae280b4ee3463fa57bbe6eede26b97daff8a0f1 upstream.
      
      When provisioning a new data block for a virtual block, either because
      the block was previously unallocated or because we are breaking sharing,
      if the whole block of data is being overwritten the bio that triggered
      the provisioning is issued immediately, skipping copying or zeroing of
      the data block.
      
      When this bio completes the new mapping is inserted in to the pool's
      metadata by process_prepared_mapping(), where the bio completion is
      signaled to the upper layers.
      
      This completion is signaled without first committing the metadata.  If
      the bio in question has the REQ_FUA flag set and the system crashes
      right after its completion and before the next metadata commit, then the
      write is lost despite the REQ_FUA flag requiring that I/O completion for
      this request must only be signaled after the data has been committed to
      non-volatile storage.
      
      Fix this by deferring the completion of overwrite bios, with the REQ_FUA
      flag set, until after the metadata has been committed.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarNikos Tsironis <ntsironis@arrikto.com>
      Acked-by: 's avatarJoe Thornber <ejt@redhat.com>
      Acked-by: 's avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: 's avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9998b44f
    • Mikulas Patocka's avatar
      dm crypt: don't overallocate the integrity tag space · 73fb3894
      Mikulas Patocka authored
      commit ff0c129d3b5ecb3df7c8f5e2236582bf745b6c5f upstream.
      
      bio_sectors() returns the value in the units of 512-byte sectors (no
      matter what the real sector size of the device).  dm-crypt multiplies
      bio_sectors() by on_disk_tag_size to calculate the space allocated for
      integrity tags.  If dm-crypt is running with sector size larger than
      512b, it allocates more data than is needed.
      
      Device Mapper trims the extra space when passing the bio to
      dm-integrity, so this bug didn't result in any visible misbehavior.
      But it must be fixed to avoid wasteful memory allocation for the block
      integrity payload.
      
      Fixes: ef43aa38 ("dm crypt: add cryptographic data integrity protection (authenticated encryption)")
      Cc: stable@vger.kernel.org # 4.12+
      Reported-by: 's avatarMilan Broz <mbroz@redhat.com>
      Signed-off-by: 's avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: 's avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73fb3894
    • Borislav Petkov's avatar
      x86/a.out: Clear the dump structure initially · 24975d23
      Borislav Petkov authored
      commit 10970e1b4be9c74fce8ab6e3c34a7d718f063f2c upstream.
      
      dump_thread32() in aout_core_dump() does not clear the user32 structure
      allocated on the stack as the first thing on function entry.
      
      As a result, the dump.u_comm, dump.u_ar0 and dump.signal which get
      assigned before the clearing, get overwritten.
      
      Rename that function to fill_dump() to make it clear what it does and
      call it first thing.
      
      This was caught while staring at a patch by Derek Robson
      <robsonde@gmail.com>.
      Signed-off-by: 's avatarBorislav Petkov <bp@suse.de>
      Cc: Derek Robson <robsonde@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Matz <matz@suse.de>
      Cc: x86@kernel.org
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20190202005512.3144-1-robsonde@gmail.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24975d23
    • Nate Dailey's avatar
      md/raid1: don't clear bitmap bits on interrupted recovery. · f4dc9d38
      Nate Dailey authored
      commit dfcc34c99f3ebc16b787b118763bf9cb6b1efc7a upstream.
      
      sync_request_write no longer submits writes to a Faulty device. This has
      the unfortunate side effect that bitmap bits can be incorrectly cleared
      if a recovery is interrupted (previously, end_sync_write would have
      prevented this). This means the next recovery may not copy everything
      it should, potentially corrupting data.
      
      Add a function for doing the proper md_bitmap_end_sync, called from
      end_sync_write and the Faulty case in sync_request_write.
      
      backport note to 4.14: s/md_bitmap_end_sync/bitmap_end_sync
      Cc: stable@vger.kernel.org 4.14+
      Fixes: 0c9d5b12 ("md/raid1: avoid reusing a resync bio after error handling.")
      Reviewed-by: 's avatarJack Wang <jinpu.wang@cloud.ionos.com>
      Tested-by: 's avatarJack Wang <jinpu.wang@cloud.ionos.com>
      Signed-off-by: 's avatarNate Dailey <nate.dailey@stratus.com>
      Signed-off-by: 's avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4dc9d38
    • Eric W. Biederman's avatar
      signal: Restore the stop PTRACE_EVENT_EXIT · 910e3b31
      Eric W. Biederman authored
      commit cf43a757fd49442bc38f76088b70c2299eed2c2f upstream.
      
      In the middle of do_exit() there is there is a call
      "ptrace_event(PTRACE_EVENT_EXIT, code);" That call places the process
      in TACKED_TRACED aka "(TASK_WAKEKILL | __TASK_TRACED)" and waits for
      for the debugger to release the task or SIGKILL to be delivered.
      
      Skipping past dequeue_signal when we know a fatal signal has already
      been delivered resulted in SIGKILL remaining pending and
      TIF_SIGPENDING remaining set.  This in turn caused the
      scheduler to not sleep in PTACE_EVENT_EXIT as it figured
      a fatal signal was pending.  This also caused ptrace_freeze_traced
      in ptrace_check_attach to fail because it left a per thread
      SIGKILL pending which is what fatal_signal_pending tests for.
      
      This difference in signal state caused strace to report
      strace: Exit of unknown pid NNNNN ignored
      
      Therefore update the signal handling state like dequeue_signal
      would when removing a per thread SIGKILL, by removing SIGKILL
      from the per thread signal mask and clearing TIF_SIGPENDING.
      Acked-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: 's avatarIvan Delalande <colona@arista.com>
      Cc: stable@vger.kernel.org
      Fixes: 35634ffa1751 ("signal: Always notice exiting tasks")
      Signed-off-by: 's avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      910e3b31
    • Hedi Berriche's avatar
      x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls · c87d8ef1
      Hedi Berriche authored
      commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.
      
      Calls into UV firmware must be protected against concurrency, expose the
      efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
      calls.
      Signed-off-by: 's avatarHedi Berriche <hedi.berriche@hpe.com>
      Signed-off-by: 's avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: 's avatarRuss Anderson <rja@hpe.com>
      Reviewed-by: 's avatarDimitri Sivanich <sivanich@hpe.com>
      Reviewed-by: 's avatarMike Travis <mike.travis@hpe.com>
      Cc: Andy Shevchenko <andy@infradead.org>
      Cc: Bhupesh Sharma <bhsharma@redhat.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-efi <linux-efi@vger.kernel.org>
      Cc: platform-driver-x86@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.9+
      Cc: Steve Wahl <steve.wahl@hpe.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c87d8ef1
    • Andreas Ziegler's avatar
      tracing/uprobes: Fix output for multiple string arguments · 092fc755
      Andreas Ziegler authored
      commit 0722069a5374b904ec1a67f91249f90e1cfae259 upstream.
      
      When printing multiple uprobe arguments as strings the output for the
      earlier arguments would also include all later string arguments.
      
      This is best explained in an example:
      
      Consider adding a uprobe to a function receiving two strings as
      parameters which is at offset 0xa0 in strlib.so and we want to print
      both parameters when the uprobe is hit (on x86_64):
      
      $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
          /sys/kernel/debug/tracing/uprobe_events
      
      When the function is called as func("foo", "bar") and we hit the probe,
      the trace file shows a line like the following:
      
        [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
      
      Note the extra "bar" printed as part of arg1. This behaviour stacks up
      for additional string arguments.
      
      The strings are stored in a dynamically growing part of the uprobe
      buffer by fetch_store_string() after copying them from userspace via
      strncpy_from_user(). The return value of strncpy_from_user() is then
      directly used as the required size for the string. However, this does
      not take the terminating null byte into account as the documentation
      for strncpy_from_user() cleary states that it "[...] returns the
      length of the string (not including the trailing NUL)" even though the
      null byte will be copied to the destination.
      
      Therefore, subsequent calls to fetch_store_string() will overwrite
      the terminating null byte of the most recently fetched string with
      the first character of the current string, leading to the
      "accumulation" of strings in earlier arguments in the output.
      
      Fix this by incrementing the return value of strncpy_from_user() by
      one if we did not hit the maximum buffer size.
      
      Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 5baaa59e ("tracing/probes: Implement 'memory' fetch method for uprobes")
      Acked-by: 's avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: 's avatarAndreas Ziegler <andreas.ziegler@fau.de>
      Signed-off-by: 's avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: 's avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      092fc755
    • Meelis Roos's avatar
      alpha: Fix Eiger NR_IRQS to 128 · 94f42cc1
      Meelis Roos authored
      commit bfc913682464f45bc4d6044084e370f9048de9d5 upstream.
      
      Eiger machine vector definition has nr_irqs 128, and working 2.6.26
      boot shows SCSI getting IRQ-s 64 and 65. Current kernel boot fails
      because Symbios SCSI fails to request IRQ-s and does not find the disks.
      It has been broken at least since 3.18 - the earliest I could test with
      my gcc-5.
      
      The headers have moved around and possibly another order of defines has
      worked in the past - but since 128 seems to be correct and used, fix
      arch/alpha/include/asm/irq.h to have NR_IRQS=128 for Eiger.
      
      This fixes 4.19-rc7 boot on my Force Flexor A264 (Eiger subarch).
      
      Cc: stable@vger.kernel.org # v3.18+
      Signed-off-by: 's avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: 's avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94f42cc1