An error occurred fetching the project authors.
  1. 01 Apr, 2019 9 commits
  2. 31 Mar, 2019 3 commits
  3. 28 Mar, 2019 4 commits
  4. 26 Mar, 2019 4 commits
  5. 14 Mar, 2019 20 commits
    • Stefan Bader's avatar
      UBUNTU: Ubuntu-4.4.0-144.170 · 6c32833f
      Stefan Bader authored
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      6c32833f
    • Stefan Bader's avatar
    • Stefan Bader's avatar
    • Stefan Bader's avatar
    • Stefan Bader's avatar
    • Ignat Loskutov's avatar
      UBUNTU: [Packaging] fix a mistype · b104e6bf
      Ignat Loskutov authored
      BugLink: https://bugs.launchpad.net/bugs/1396654
      
      HAVE_CPLUS_DEMANGLE_SUPPORT=1 used to be spelled incorrectly, leading to
      missing C++ demangling support in perf.
      Signed-off-by: default avatarIgnat Loskutov <ignat.loskutov@gmail.com>
      Acked-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      Acked-by: default avatarYou-Sheng Yang <vicamo.yang@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      b104e6bf
    • Jann Horn's avatar
      mm: enforce min addr even if capable() in expand_downwards() · 0210a634
      Jann Horn authored
      security_mmap_addr() does a capability check with current_cred(), but
      we can reach this code from contexts like a VFS write handler where
      current_cred() must not be used.
      
      This can be abused on systems without SMAP to make NULL pointer
      dereferences exploitable again.
      
      Fixes: 8869477a ("security: protect from stack expansion into low vm addresses")
      Cc: stable@kernel.org
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      
      CVE-2019-9213
      
      (cherry picked from commit 0a1d5299)
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Acked-By: default avatarYou-Sheng Yang <vicamo.yang@canonical.com>
      Acked-by: default avatarKleber Sacilotto de Souza <kleber.souza@canonical.com>
      Signed-off-by: default avatarKleber Sacilotto de Souza <kleber.souza@canonical.com>
      0210a634
    • Marcel Holtmann's avatar
      Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt · dfcfffc1
      Marcel Holtmann authored
      When doing option parsing for standard type values of 1, 2 or 4 octets,
      the value is converted directly into a variable instead of a pointer. To
      avoid being tricked into being a pointer, check that for these option
      types that sizes actually match. In L2CAP every option is fixed size and
      thus it is prudent anyway to ensure that the remote side sends us the
      right option size along with option paramters.
      
      If the option size is not matching the option type, then that option is
      silently ignored. It is a protocol violation and instead of trying to
      give the remote attacker any further hints just pretend that option is
      not present and proceed with the default values. Implementation
      following the specification and its qualification procedures will always
      use the correct size and thus not being impacted here.
      
      To keep the code readable and consistent accross all options, a few
      cosmetic changes were also required.
      
      CVE-2019-3460
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      (cherry picked from commit af3d5d1c)
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Acked-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Acked-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatarKleber Sacilotto de Souza <kleber.souza@canonical.com>
      dfcfffc1
    • Greg Kroah-Hartman's avatar
    • Eric Dumazet's avatar
      ax25: fix possible use-after-free · f8efc611
      Eric Dumazet authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      commit 63530aba 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: default avatarEric Dumazet <edumazet@google.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      f8efc611
    • Eric Dumazet's avatar
      mISDN: fix a race in dev_expire_timer() · 0ee7fcc9
      Eric Dumazet authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      commit bdcc5bc2 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: default avatarEric Dumazet <edumazet@google.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      0ee7fcc9
    • Eric Dumazet's avatar
      net/x25: do not hold the cpu too long in x25_new_lci() · c2e9f2d6
      Eric Dumazet authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      commit cf657d22 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: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Andrew Hendry <andrew.hendry@gmail.com>
      Cc: linux-x25@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      c2e9f2d6
    • Arnd Bergmann's avatar
      mfd: as3722: Mark PM functions as __maybe_unused · f22d0419
      Arnd Bergmann authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      commit a7b956fd upstream.
      
      The newly introduced as3722_i2c_suspend/resume functions are built
      unconditionally, but only used when power management is enabled,
      so we get a warning otherwise:
      
      drivers/mfd/as3722.c:427:12: warning: 'as3722_i2c_suspend' defined but not used [-Wunused-function]
      drivers/mfd/as3722.c:438:12: warning: 'as3722_i2c_resume' defined but not used [-Wunused-function]
      
      This marks them both as __maybe_unused, which avoids an ugly #ifdef
      and gives us best compile-time coverage. When they are unused, the
      compiler will silently drop the functions from its output.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 35deff7e ("mfd: as3722: Handle interrupts on suspend")
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Cc: Jon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      f22d0419
    • Jon Hunter's avatar
      mfd: as3722: Handle interrupts on suspend · 95e548d7
      Jon Hunter authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      commit 35deff7e upstream.
      
      The as3722 device is registered as an irqchip and the as3722-rtc interrupt
      is one of it's interrupt sources. When using the as3722-rtc as a wake-up
      device from suspend, the following is seen:
      
        PM: Syncing filesystems ... done.
        Freezing user space processes ... (elapsed 0.001 seconds) done.
        Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
        Suspending console(s) (use no_console_suspend to debug)
        PM: suspend of devices complete after 161.119 msecs
        PM: late suspend of devices complete after 1.048 msecs
        PM: noirq suspend of devices complete after 0.756 msecs
        Disabling non-boot CPUs ...
        CPU1: shutdown
        CPU2: shutdown
        CPU3: shutdown
        Entering suspend state LP1
        Enabling non-boot CPUs ...
        CPU1 is up
        CPU2 is up
        CPU3 is up
        PM: noirq resume of devices complete after 0.487 msecs
        as3722 4-0040: Failed to read IRQ status: -16
        as3722 4-0040: Failed to read IRQ status: -16
        as3722 4-0040: Failed to read IRQ status: -16
        as3722 4-0040: Failed to read IRQ status: -16
        ...
      
      The reason why the as3722 interrupt status cannot be read is because the
      as3722 interrupt is not masked during suspend and when the as3722-rtc
      interrupt occurs, to wake-up the device, the interrupt is seen before the
      i2c controller has been resumed in order to read the as3722 interrupt
      status.
      
      The as3722-rtc driver sets it's interrupt as a wake-up source during
      suspend, which gets propagated to the parent as3722 interrupt. However,
      the as3722-rtc driver cannot disable it's interrupt during suspend
      otherwise we would never be woken up and so the as3722 must disable it's
      interrupt instead.
      
      Fix this by disabling the as3722 interrupt during suspend. To ensure that
      a wake-up event from the as3722 is not missing, enable the as3722 interrupt
      as a wake-up source before disabling the interrupt on entering suspend.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      95e548d7
    • chenzefeng (A)'s avatar
      x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32 · 30230644
      chenzefeng (A) authored
      BugLink: https://bugs.launchpad.net/bugs/1818815Signed-off-by: default avatarchenzefeng <chenzefeng2@huawei.com>
      
      On x86-64, for 32-bit PC-relacive branches, we can generate PLT32
      relocation, instead of PC32 relocation. and R_X86_64_PLT32 can be
      treated the same as R_X86_64_PC32 since linux kernel doesn't use PLT.
      
      commit b21ebf2f ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") been
      fixed for the module loading, but not fixed for livepatch relocation,
      which will fail to load livepatch with the error message as follow:
      relocation failed for symbol <symbol name> at <symbol address>
      
      This issue only effacted the kernel version from 4.0 to 4.6, becauce the
      function klp_write_module_reloc is introduced by: commit b700e7f0
      ("livepatch: kernel: add support for live patching") and deleted by:
      commit 425595a7 ("livepatch: reuse module loader code to write
      relocations")
      Signed-off-by: default avatarchenzefeng <chenzefeng2@huawei.com>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      30230644
    • Lorenzo Bianconi's avatar
      net: ipv4: use a dedicated counter for icmp_v4 redirect packets · 2b059e5b
      Lorenzo Bianconi authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      [ Upstream commit c09551c6 ]
      
      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: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      2b059e5b
    • Jose Abreu's avatar
      net: stmmac: Fix a race in EEE enable callback · 6abaacfb
      Jose Abreu authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      [ Upstream commit 8a7493e5 ]
      
      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: default 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: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      6abaacfb
    • Eric Dumazet's avatar
      vxlan: test dev->flags & IFF_UP before calling netif_rx() · 536838d5
      Eric Dumazet authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      [ Upstream commit 4179cb5a ]
      
      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: default 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: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      536838d5
    • Eric Dumazet's avatar
      tcp: clear icsk_backoff in tcp_write_queue_purge() · 4f381ea4
      Eric Dumazet authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      [ Upstream commit 04c03114 ]
      
      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: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsoukjin bae <soukjin.bae@samsung.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      4f381ea4
    • Alexander Duyck's avatar
      net: Do not allocate page fragments that are not skb aligned · 315bc349
      Alexander Duyck authored
      BugLink: https://bugs.launchpad.net/bugs/1818815
      
      [ Upstream commit 3bed3cc4 ]
      
      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: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJuerg Haefliger <juergh@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      315bc349