commit af13f43f01a3e4a11686f5fa4de42ecec8ed71b1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Feb 23 09:05:14 2019 +0100

    Linux 4.4.176

commit 49e1a9d1169adcffee99967130ff6d3b79d5fbe6
Author: Joerg Roedel <jroedel@suse.de>
Date:   Thu Feb 21 14:52:13 2019 +0100

    KVM: VMX: Fix x2apic check in vmx_msr_bitmap_mode()
    
    The stable backport of upstream commit
    
            904e14fb7cb96 KVM: VMX: make MSR bitmaps per-VCPU
    
    has a bug in vmx_msr_bitmap_mode(). It enables the x2apic
    MSR-bitmap when the kernel emulates x2apic for the guest in
    software. The upstream version of the commit checkes whether
    the hardware has virtualization enabled for x2apic
    emulation.
    
    Since KVM emulates x2apic for guests even when the host does
    not support x2apic in hardware, this causes the intercept of
    at least the X2APIC_TASKPRI MSR to be disabled on machines
    not supporting that MSR. The result is undefined behavior,
    on some machines (Intel Westmere based) it causes a crash of
    the guest kernel when it tries to access that MSR.
    
    Change the check in vmx_msr_bitmap_mode() to match the upstream
    code. This fixes the guest crashes observed with stable
    kernels starting with v4.4.168 through v4.4.175.
    
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94801fd5ab2352830a86ca59b1e6377e35b6a074
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 22 10:40:59 2019 -0800

    ax25: fix possible use-after-free
    
    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: Eric Dumazet <edumazet@google.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c532eb1d4527d45962b6e14720f6d8c51b688889
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Feb 5 15:38:44 2019 -0800

    mISDN: fix a race in dev_expire_timer()
    
    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: Eric Dumazet <edumazet@google.com>
    Cc: Karsten Keil <isdn@linux-pingi.de>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82379cf03bee3b8f7d2973363723f561dfe5c9c0
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 8 12:41:05 2019 -0800

    net/x25: do not hold the cpu too long in x25_new_lci()
    
    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: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Andrew Hendry <andrew.hendry@gmail.com>
    Cc: linux-x25@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c78c9f52afe57848a5262afe3c12c7d9930d0831
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Dec 8 16:21:05 2015 +0100

    mfd: as3722: Mark PM functions as __maybe_unused
    
    commit a7b956fd38dd217dd78e3058110929f5ac914df1 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: Arnd Bergmann <arnd@arndb.de>
    Fixes: 35deff7eb212 ("mfd: as3722: Handle interrupts on suspend")
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Cc: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7dff89d771365d2d96e7584a633e196448fefcf
Author: Jon Hunter <jonathanh@nvidia.com>
Date:   Fri Nov 20 10:51:00 2015 +0000

    mfd: as3722: Handle interrupts on suspend
    
    commit 35deff7eb212b661b32177b6043f674fde6314d7 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: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc4db52485cc6edfd6861417d178bb71f743ced7
Author: Jann Horn <jannh@google.com>
Date:   Sat Jan 26 01:54:33 2019 +0100

    kvm: fix kvm_ioctl_create_device() reference counting (CVE-2019-6974)
    
    commit cfa39381173d5f969daf43582c95ad679189cbc9 upstream.
    
    kvm_ioctl_create_device() does the following:
    
    1. creates a device that holds a reference to the VM object (with a borrowed
       reference, the VM's refcount has not been bumped yet)
    2. initializes the device
    3. transfers the reference to the device to the caller's file descriptor table
    4. calls kvm_get_kvm() to turn the borrowed reference to the VM into a real
       reference
    
    The ownership transfer in step 3 must not happen before the reference to the VM
    becomes a proper, non-borrowed reference, which only happens in step 4.
    After step 3, an attacker can close the file descriptor and drop the borrowed
    reference, which can cause the refcount of the kvm object to drop to zero.
    
    This means that we need to grab a reference for the device before
    anon_inode_getfd(), otherwise the VM can disappear from under us.
    
    Fixes: 852b6d57dc7f ("kvm: add device control API")
    Cc: stable@kernel.org
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5aebe74113f488cad5444ab66f28c08d9c0a39a
Author: chenzefeng (A) <chenzefeng2@huawei.com>
Date:   Wed Feb 20 12:37:54 2019 +0000

    x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32
    
    Signed-off-by: chenzefeng <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 b21ebf2fb4cd ("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 b700e7f03df5
    ("livepatch: kernel: add support for live patching") and deleted by:
    commit 425595a7fc20 ("livepatch: reuse module loader code to write
    relocations")
    
    Signed-off-by: chenzefeng <chenzefeng2@huawei.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01fb36063d972e1b1ac751d9249300098ba20794
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date:   Wed Feb 6 19:18:04 2019 +0100

    net: ipv4: use a dedicated counter for icmp_v4 redirect packets
    
    [ 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 1da177e4c3f4 ("Linux-2.6.12-rc2")
    
    Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fa6a285279f2aab6455026c08b2bad4d972cefa
Author: Jose Abreu <jose.abreu@synopsys.com>
Date:   Mon Feb 18 14:35:03 2019 +0100

    net: stmmac: Fix a race in EEE enable callback
    
    [ 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: Jose Abreu <joabreu@synopsys.com>
    Fixes: d765955d2ae0 ("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: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffed570a85ad163d3d4d3573941da6998ae2c0dc
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 7 12:27:38 2019 -0800

    vxlan: test dev->flags & IFF_UP before calling netif_rx()
    
    [ 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 ce6502a8f957 ("vxlan: fix a use after free
    in vxlan_encap_bypass"), since the dev->stats.rx_dropped
    change was done on the wrong device.
    
    Fixes: d342894c5d2f ("vxlan: virtual extensible lan")
    Fixes: ce6502a8f957 ("vxlan: fix a use after free in vxlan_encap_bypass")
    Signed-off-by: Eric 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: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a466589807a13da2b7fbb2776e01634b38a4233b
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 15 13:36:20 2019 -0800

    tcp: clear icsk_backoff in tcp_write_queue_purge()
    
    [ 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: Eric Dumazet <edumazet@google.com>
    Reported-by: soukjin bae <soukjin.bae@samsung.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e7b872833c72bca349f50feec83bf352664937a
Author: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Date:   Fri Feb 15 14:44:18 2019 -0800

    net: Do not allocate page fragments that are not skb aligned
    
    [ 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: ffde7328a36d ("net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 122e4a30779336643614fe0f81e1f3fcbd0a371c
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 15 13:36:21 2019 -0800

    tcp: tcp_v4_err() should be more careful
    
    [ 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: Eric Dumazet <edumazet@google.com>
    Reported-by: soukjin bae <soukjin.bae@samsung.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 817d4a4295661c0864919db213d9a81b0d2db6f7
Author: David S. Miller <davem@davemloft.net>
Date:   Sat Feb 16 13:44:39 2019 -0800

    net: Add header for usage of fls64()
    
    [ Upstream commit 8681ef1f3d295bd3600315325f3b3396d76d02f6 ]
    
    Fixes: 3b89ea9c5902 ("net: Fix for_each_netdev_feature on Big endian")
    Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fecacc0d5ff0dfabb1b9358279ca316cd0bbda6
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Feb 19 23:45:29 2019 +0800

    sky2: Increase D3 delay again
    
    [ 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/1798921
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1815d11b544aad4bbc67b614fed560eb8ffbce4b
Author: Hauke Mehrtens <hauke.mehrtens@intel.com>
Date:   Fri Feb 15 17:58:54 2019 +0100

    net: Fix for_each_netdev_feature on Big endian
    
    [ 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: fd867d51f ("net/core: generic support for disabling netdev features down stack")
    Signed-off-by: Hauke Mehrtens <hauke.mehrtens@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27763b01a4ff6a7cd87ed388f317ac489631468b
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Wed Dec 26 11:28:24 2018 +0000

    hwmon: (lm80) Fix missing unlock on error in set_fan_div()
    
    [ 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: Wei Yongjun <weiyongjun1@huawei.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d6ca4d88e276a61fac3e6b47908f2abb0e6f3ae
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 7 14:13:18 2019 +0100

    vsock: cope with memory allocation failure at socket creation time
    
    [ 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: Xiumei Mu <xmu@redhat.com>
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9467d98f6d484257ddb6004721a4e2c957c39c73
Author: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Date:   Mon Feb 11 10:57:46 2019 +0800

    net: fix IPv6 prefix route residue
    
    [ 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: 5b84efecb7d9 ("ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE")
    Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
    Reported-by: Wenhao Zhang <zhangwenhao8@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>