commit 3b68e5cf57f08ad1a9dd7f8ca48ae1326ac98824
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jan 23 08:09:52 2019 +0100

    Linux 4.14.95

commit c2912ca3f893a14fd24a6cad165acf61f4d7bc01
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jan 14 09:48:09 2019 +0100

    nbd: Use set_blocksize() to set device blocksize
    
    commit c8a83a6b54d0ca078de036aafb3f6af58c1dc5eb upstream.
    
    NBD can update block device block size implicitely through
    bd_set_size(). Make it explicitely set blocksize with set_blocksize() as
    this behavior of bd_set_size() is going away.
    
    CC: Josef Bacik <jbacik@fb.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4381a9484b4772589021c61e682177e1602b32fb
Author: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Date:   Fri Nov 23 07:05:58 2018 -0500

    media: vb2: be sure to unlock mutex on errors
    
    commit c06ef2e9acef4cda1feee2ce055b8086e33d251a upstream.
    
    As reported by smatch:
    drivers/media/common/videobuf2/videobuf2-core.c: drivers/media/common/videobuf2/videobuf2-core.c:2159 vb2_mmap() warn: inconsistent returns 'mutex:&q->mmap_lock'.
      Locked on:   line 2148
      Unlocked on: line 2100
                   line 2108
                   line 2113
                   line 2118
                   line 2156
                   line 2159
    
    There is one error condition that doesn't unlock a mutex.
    
    Fixes: cd26d1c4d1bc ("media: vb2: vb2_mmap: move lock up")
    Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 787d30991a505a5c837389704f8be5e12547e652
Author: Ivan Mironov <mironov.ivan@gmail.com>
Date:   Tue Jan 8 12:23:53 2019 +0500

    drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock
    
    commit 66a8d5bfb518f9f12d47e1d2dce1732279f9451e upstream.
    
    Strict requirement of pixclock to be zero breaks support of SDL 1.2
    which contains hardcoded table of supported video modes with non-zero
    pixclock values[1].
    
    To better understand which pixclock values are considered valid and how
    driver should handle these values, I briefly examined few existing fbdev
    drivers and documentation in Documentation/fb/. And it looks like there
    are no strict rules on that and actual behaviour varies:
    
            * some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c);
            * some treat (pixclock == 0) as invalid value which leads to
              -EINVAL (clps711x-fb.c);
            * some pass converted pixclock value to hardware (uvesafb.c);
            * some are trying to find nearest value from predefined table
              (vga16fb.c, video_gx.c).
    
    Given this, I believe that it should be safe to just ignore this value if
    changing is not supported. It seems that any portable fbdev application
    which was not written only for one specific device working under one
    specific kernel version should not rely on any particular behaviour of
    pixclock anyway.
    
    However, while enabling SDL1 applications to work out of the box when
    there is no /etc/fb.modes with valid settings, this change affects the
    video mode choosing logic in SDL. Depending on current screen
    resolution, contents of /etc/fb.modes and resolution requested by
    application, this may lead to user-visible difference (not always):
    image will be displayed in a right way, but it will be aligned to the
    left instead of center. There is no "right behaviour" here as well, as
    emulated fbdev, opposing to old fbdev drivers, simply ignores any
    requsts of video mode changes with resolutions smaller than current.
    
    The easiest way to reproduce this problem is to install sdl-sopwith[2],
    remove /etc/fb.modes file if it exists, and then try to run sopwith
    from console without X. At least in Fedora 29, sopwith may be simply
    installed from standard repositories.
    
    [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings
    [2] http://sdl-sopwith.sourceforge.net/
    
    Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
    Cc: stable@vger.kernel.org
    Fixes: 79e539453b34e ("DRM: i915: add mode setting support")
    Fixes: 771fe6b912fca ("drm/radeon: introduce kernel modesetting for radeon hardware")
    Fixes: 785b93ef8c309 ("drm/kms: move driver specific fb common code to helper functions (v2)")
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-3-mironov.ivan@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45662e4b717c7579e49a5e5c5086c543d15af0c4
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Wed Jan 9 19:17:14 2019 -0800

    loop: drop caches if offset or block_size are changed
    
    commit 5db470e229e22b7eda6e23b5566e532c96fb5bc3 upstream.
    
    If we don't drop caches used in old offset or block_size, we can get old data
    from new offset/block_size, which gives unexpected data to user.
    
    For example, Martijn found a loopback bug in the below scenario.
    1) LOOP_SET_FD loads first two pages on loop file
    2) LOOP_SET_STATUS64 changes the offset on the loop file
    3) mount is failed due to the cached pages having wrong superblock
    
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: linux-block@vger.kernel.org
    Reported-by: Martijn Coenen <maco@google.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2762edcb6af99fc9322bab0b1d4e71a427760e8
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Nov 12 08:42:14 2018 -0700

    loop: Fix double mutex_unlock(&loop_ctl_mutex) in loop_control_ioctl()
    
    commit 628bd85947091830a8c4872adfd5ed1d515a9cf2 upstream.
    
    Commit 0a42e99b58a20883 ("loop: Get rid of loop_index_mutex") forgot to
    remove mutex_unlock(&loop_ctl_mutex) from loop_control_ioctl() when
    replacing loop_index_mutex with loop_ctl_mutex.
    
    Fixes: 0a42e99b58a20883 ("loop: Get rid of loop_index_mutex")
    Reported-by: syzbot <syzbot+c0138741c2290fc5e63f@syzkaller.appspotmail.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1e63df4f30c3918476ac9bc594355b0e9629893
Author: Jan Kara <jack@suse.cz>
Date:   Thu Nov 8 14:01:04 2018 +0100

    loop: Get rid of loop_index_mutex
    
    commit 0a42e99b58a208839626465af194cfe640ef9493 upstream.
    
    Now that loop_ctl_mutex is global, just get rid of loop_index_mutex as
    there is no good reason to keep these two separate and it just
    complicates the locking.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1e81ba8a3fa56dcc48828869b392b29559a0ac3
Author: Jan Kara <jack@suse.cz>
Date:   Thu Nov 8 14:01:03 2018 +0100

    loop: Fold __loop_release into loop_release
    
    commit 967d1dc144b50ad005e5eecdfadfbcfb399ffff6 upstream.
    
    __loop_release() has a single call site. Fold it there. This is
    currently not a huge win but it will make following replacement of
    loop_index_mutex more obvious.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57da9a9742200f391d1cf93fea389f7ddc25ec9a
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Thu Nov 8 14:01:02 2018 +0100

    block/loop: Use global lock for ioctl() operation.
    
    commit 310ca162d779efee8a2dc3731439680f3e9c1e86 upstream.
    
    syzbot is reporting NULL pointer dereference [1] which is caused by
    race condition between ioctl(loop_fd, LOOP_CLR_FD, 0) versus
    ioctl(other_loop_fd, LOOP_SET_FD, loop_fd) due to traversing other
    loop devices at loop_validate_file() without holding corresponding
    lo->lo_ctl_mutex locks.
    
    Since ioctl() request on loop devices is not frequent operation, we don't
    need fine grained locking. Let's use global lock in order to allow safe
    traversal at loop_validate_file().
    
    Note that syzbot is also reporting circular locking dependency between
    bdev->bd_mutex and lo->lo_ctl_mutex [2] which is caused by calling
    blkdev_reread_part() with lock held. This patch does not address it.
    
    [1] https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3
    [2] https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reported-by: syzbot <syzbot+bf89c128e05dd6c62523@syzkaller.appspotmail.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06ee6e217586a1944cb9d50b3a2141cb060b7128
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Thu Nov 8 14:01:01 2018 +0100

    block/loop: Don't grab "struct file" for vfs_getattr() operation.
    
    commit b1ab5fa309e6c49e4e06270ec67dd7b3e9971d04 upstream.
    
    vfs_getattr() needs "struct path" rather than "struct file".
    Let's use path_get()/path_put() rather than get_file()/fput().
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f3dd37ef84bd0a07d14d260ec16e166a470c065
Author: Ying Xue <ying.xue@windriver.com>
Date:   Mon Jan 14 17:22:29 2019 +0800

    tipc: fix uninit-value in tipc_nl_compat_doit
    
    commit 2753ca5d9009c180dbfd4c802c80983b4b6108d1 upstream.
    
    BUG: KMSAN: uninit-value in tipc_nl_compat_doit+0x404/0xa10 net/tipc/netlink_compat.c:335
    CPU: 0 PID: 4514 Comm: syz-executor485 Not tainted 4.16.0+ #87
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:17 [inline]
     dump_stack+0x185/0x1d0 lib/dump_stack.c:53
     kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
     __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
     tipc_nl_compat_doit+0x404/0xa10 net/tipc/netlink_compat.c:335
     tipc_nl_compat_recv+0x164b/0x2700 net/tipc/netlink_compat.c:1153
     genl_family_rcv_msg net/netlink/genetlink.c:599 [inline]
     genl_rcv_msg+0x1686/0x1810 net/netlink/genetlink.c:624
     netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2447
     genl_rcv+0x63/0x80 net/netlink/genetlink.c:635
     netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
     netlink_unicast+0x166b/0x1740 net/netlink/af_netlink.c:1337
     netlink_sendmsg+0x1048/0x1310 net/netlink/af_netlink.c:1900
     sock_sendmsg_nosec net/socket.c:630 [inline]
     sock_sendmsg net/socket.c:640 [inline]
     ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
     __sys_sendmsg net/socket.c:2080 [inline]
     SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
     SyS_sendmsg+0x54/0x80 net/socket.c:2087
     do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
     entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    RIP: 0033:0x43fda9
    RSP: 002b:00007ffd0c184ba8 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fda9
    RDX: 0000000000000000 RSI: 0000000020023000 RDI: 0000000000000003
    RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
    R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004016d0
    R13: 0000000000401760 R14: 0000000000000000 R15: 0000000000000000
    
    Uninit was created at:
     kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
     kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
     kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
     kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
     slab_post_alloc_hook mm/slab.h:445 [inline]
     slab_alloc_node mm/slub.c:2737 [inline]
     __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
     __kmalloc_reserve net/core/skbuff.c:138 [inline]
     __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
     alloc_skb include/linux/skbuff.h:984 [inline]
     netlink_alloc_large_skb net/netlink/af_netlink.c:1183 [inline]
     netlink_sendmsg+0x9a6/0x1310 net/netlink/af_netlink.c:1875
     sock_sendmsg_nosec net/socket.c:630 [inline]
     sock_sendmsg net/socket.c:640 [inline]
     ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
     __sys_sendmsg net/socket.c:2080 [inline]
     SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
     SyS_sendmsg+0x54/0x80 net/socket.c:2087
     do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
     entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    
    In tipc_nl_compat_recv(), when the len variable returned by
    nlmsg_attrlen() is 0, the message is still treated as a valid one,
    which is obviously unresonable. When len is zero, it means the
    message not only doesn't contain any valid TLV payload, but also
    TLV header is not included. Under this stituation, tlv_type field
    in TLV header is still accessed in tipc_nl_compat_dumpit() or
    tipc_nl_compat_doit(), but the field space is obviously illegal.
    Of course, it is not initialized.
    
    Reported-by: syzbot+bca0dc46634781f08b38@syzkaller.appspotmail.com
    Reported-by: syzbot+6bdb590321a7ae40c1a6@syzkaller.appspotmail.com
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2aae1723dea1235ffef183daf0694805297424f6
Author: Ying Xue <ying.xue@windriver.com>
Date:   Mon Jan 14 17:22:28 2019 +0800

    tipc: fix uninit-value in tipc_nl_compat_name_table_dump
    
    commit 974cb0e3e7c963ced06c4e32c5b2884173fa5e01 upstream.
    
    syzbot reported:
    
    BUG: KMSAN: uninit-value in __arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline]
    BUG: KMSAN: uninit-value in __fswab32 include/uapi/linux/swab.h:59 [inline]
    BUG: KMSAN: uninit-value in tipc_nl_compat_name_table_dump+0x4a8/0xba0 net/tipc/netlink_compat.c:826
    CPU: 0 PID: 6290 Comm: syz-executor848 Not tainted 4.19.0-rc8+ #70
    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+0x306/0x460 lib/dump_stack.c:113
     kmsan_report+0x1a2/0x2e0 mm/kmsan/kmsan.c:917
     __msan_warning+0x7c/0xe0 mm/kmsan/kmsan_instr.c:500
     __arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline]
     __fswab32 include/uapi/linux/swab.h:59 [inline]
     tipc_nl_compat_name_table_dump+0x4a8/0xba0 net/tipc/netlink_compat.c:826
     __tipc_nl_compat_dumpit+0x59e/0xdb0 net/tipc/netlink_compat.c:205
     tipc_nl_compat_dumpit+0x63a/0x820 net/tipc/netlink_compat.c:270
     tipc_nl_compat_handle net/tipc/netlink_compat.c:1151 [inline]
     tipc_nl_compat_recv+0x1402/0x2760 net/tipc/netlink_compat.c:1210
     genl_family_rcv_msg net/netlink/genetlink.c:601 [inline]
     genl_rcv_msg+0x185c/0x1a20 net/netlink/genetlink.c:626
     netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2454
     genl_rcv+0x63/0x80 net/netlink/genetlink.c:637
     netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
     netlink_unicast+0x166d/0x1720 net/netlink/af_netlink.c:1343
     netlink_sendmsg+0x1391/0x1420 net/netlink/af_netlink.c:1908
     sock_sendmsg_nosec net/socket.c:621 [inline]
     sock_sendmsg net/socket.c:631 [inline]
     ___sys_sendmsg+0xe47/0x1200 net/socket.c:2116
     __sys_sendmsg net/socket.c:2154 [inline]
     __do_sys_sendmsg net/socket.c:2163 [inline]
     __se_sys_sendmsg+0x307/0x460 net/socket.c:2161
     __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
     do_syscall_64+0xbe/0x100 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    RIP: 0033:0x440179
    Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007ffecec49318 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440179
    RDX: 0000000000000000 RSI: 0000000020000100 RDI: 0000000000000003
    RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
    R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401a00
    R13: 0000000000401a90 R14: 0000000000000000 R15: 0000000000000000
    
    Uninit was created at:
     kmsan_save_stack_with_flags mm/kmsan/kmsan.c:255 [inline]
     kmsan_internal_poison_shadow+0xc8/0x1d0 mm/kmsan/kmsan.c:180
     kmsan_kmalloc+0xa4/0x120 mm/kmsan/kmsan_hooks.c:104
     kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:113
     slab_post_alloc_hook mm/slab.h:446 [inline]
     slab_alloc_node mm/slub.c:2727 [inline]
     __kmalloc_node_track_caller+0xb43/0x1400 mm/slub.c:4360
     __kmalloc_reserve net/core/skbuff.c:138 [inline]
     __alloc_skb+0x422/0xe90 net/core/skbuff.c:206
     alloc_skb include/linux/skbuff.h:996 [inline]
     netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
     netlink_sendmsg+0xcaf/0x1420 net/netlink/af_netlink.c:1883
     sock_sendmsg_nosec net/socket.c:621 [inline]
     sock_sendmsg net/socket.c:631 [inline]
     ___sys_sendmsg+0xe47/0x1200 net/socket.c:2116
     __sys_sendmsg net/socket.c:2154 [inline]
     __do_sys_sendmsg net/socket.c:2163 [inline]
     __se_sys_sendmsg+0x307/0x460 net/socket.c:2161
     __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
     do_syscall_64+0xbe/0x100 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    
    We cannot take for granted the thing that the length of data contained
    in TLV is longer than the size of struct tipc_name_table_query in
    tipc_nl_compat_name_table_dump().
    
    Reported-by: syzbot+06e771a754829716a327@syzkaller.appspotmail.com
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8123f1b363e44da4607aafa4de92e86a71ca1f82
Author: Ying Xue <ying.xue@windriver.com>
Date:   Mon Jan 14 17:22:27 2019 +0800

    tipc: fix uninit-value in tipc_nl_compat_link_set
    
    commit edf5ff04a45750ac8ce2435974f001dc9cfbf055 upstream.
    
    syzbot reports following splat:
    
    BUG: KMSAN: uninit-value in strlen+0x3b/0xa0 lib/string.c:486
    CPU: 1 PID: 9306 Comm: syz-executor172 Not tainted 4.20.0-rc7+ #2
    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+0x173/0x1d0 lib/dump_stack.c:113
      kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
      __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313
      strlen+0x3b/0xa0 lib/string.c:486
      nla_put_string include/net/netlink.h:1154 [inline]
      __tipc_nl_compat_link_set net/tipc/netlink_compat.c:708 [inline]
      tipc_nl_compat_link_set+0x929/0x1220 net/tipc/netlink_compat.c:744
      __tipc_nl_compat_doit net/tipc/netlink_compat.c:311 [inline]
      tipc_nl_compat_doit+0x3aa/0xaf0 net/tipc/netlink_compat.c:344
      tipc_nl_compat_handle net/tipc/netlink_compat.c:1107 [inline]
      tipc_nl_compat_recv+0x14d7/0x2760 net/tipc/netlink_compat.c:1210
      genl_family_rcv_msg net/netlink/genetlink.c:601 [inline]
      genl_rcv_msg+0x185f/0x1a60 net/netlink/genetlink.c:626
      netlink_rcv_skb+0x444/0x640 net/netlink/af_netlink.c:2477
      genl_rcv+0x63/0x80 net/netlink/genetlink.c:637
      netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
      netlink_unicast+0xf40/0x1020 net/netlink/af_netlink.c:1336
      netlink_sendmsg+0x127f/0x1300 net/netlink/af_netlink.c:1917
      sock_sendmsg_nosec net/socket.c:621 [inline]
      sock_sendmsg net/socket.c:631 [inline]
      ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2116
      __sys_sendmsg net/socket.c:2154 [inline]
      __do_sys_sendmsg net/socket.c:2163 [inline]
      __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
      __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
      do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
      entry_SYSCALL_64_after_hwframe+0x63/0xe7
    
    The uninitialised access happened in
        nla_put_string(skb, TIPC_NLA_LINK_NAME, lc->name)
    
    This is because lc->name string is not validated before it's used.
    
    Reported-by: syzbot+d78b8a29241a195aefb8@syzkaller.appspotmail.com
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6129b69a0a9db48a82cb207f96cde1f0f1b39dec
Author: Ying Xue <ying.xue@windriver.com>
Date:   Mon Jan 14 17:22:26 2019 +0800

    tipc: fix uninit-value in tipc_nl_compat_bearer_enable
    
    commit 0762216c0ad2a2fccd63890648eca491f2c83d9a upstream.
    
    syzbot reported:
    
    BUG: KMSAN: uninit-value in strlen+0x3b/0xa0 lib/string.c:484
    CPU: 1 PID: 6371 Comm: syz-executor652 Not tainted 4.19.0-rc8+ #70
    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+0x306/0x460 lib/dump_stack.c:113
     kmsan_report+0x1a2/0x2e0 mm/kmsan/kmsan.c:917
     __msan_warning+0x7c/0xe0 mm/kmsan/kmsan_instr.c:500
     strlen+0x3b/0xa0 lib/string.c:484
     nla_put_string include/net/netlink.h:1011 [inline]
     tipc_nl_compat_bearer_enable+0x238/0x7b0 net/tipc/netlink_compat.c:389
     __tipc_nl_compat_doit net/tipc/netlink_compat.c:311 [inline]
     tipc_nl_compat_doit+0x39f/0xae0 net/tipc/netlink_compat.c:344
     tipc_nl_compat_recv+0x147c/0x2760 net/tipc/netlink_compat.c:1107
     genl_family_rcv_msg net/netlink/genetlink.c:601 [inline]
     genl_rcv_msg+0x185c/0x1a20 net/netlink/genetlink.c:626
     netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2454
     genl_rcv+0x63/0x80 net/netlink/genetlink.c:637
     netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
     netlink_unicast+0x166d/0x1720 net/netlink/af_netlink.c:1343
     netlink_sendmsg+0x1391/0x1420 net/netlink/af_netlink.c:1908
     sock_sendmsg_nosec net/socket.c:621 [inline]
     sock_sendmsg net/socket.c:631 [inline]
     ___sys_sendmsg+0xe47/0x1200 net/socket.c:2116
     __sys_sendmsg net/socket.c:2154 [inline]
     __do_sys_sendmsg net/socket.c:2163 [inline]
     __se_sys_sendmsg+0x307/0x460 net/socket.c:2161
     __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
     do_syscall_64+0xbe/0x100 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    RIP: 0033:0x440179
    Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007fffef7beee8 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440179
    RDX: 0000000000000000 RSI: 0000000020000100 RDI: 0000000000000003
    RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
    R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401a00
    R13: 0000000000401a90 R14: 0000000000000000 R15: 0000000000000000
    
    Uninit was created at:
     kmsan_save_stack_with_flags mm/kmsan/kmsan.c:255 [inline]
     kmsan_internal_poison_shadow+0xc8/0x1d0 mm/kmsan/kmsan.c:180
     kmsan_kmalloc+0xa4/0x120 mm/kmsan/kmsan_hooks.c:104
     kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:113
     slab_post_alloc_hook mm/slab.h:446 [inline]
     slab_alloc_node mm/slub.c:2727 [inline]
     __kmalloc_node_track_caller+0xb43/0x1400 mm/slub.c:4360
     __kmalloc_reserve net/core/skbuff.c:138 [inline]
     __alloc_skb+0x422/0xe90 net/core/skbuff.c:206
     alloc_skb include/linux/skbuff.h:996 [inline]
     netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
     netlink_sendmsg+0xcaf/0x1420 net/netlink/af_netlink.c:1883
     sock_sendmsg_nosec net/socket.c:621 [inline]
     sock_sendmsg net/socket.c:631 [inline]
     ___sys_sendmsg+0xe47/0x1200 net/socket.c:2116
     __sys_sendmsg net/socket.c:2154 [inline]
     __do_sys_sendmsg net/socket.c:2163 [inline]
     __se_sys_sendmsg+0x307/0x460 net/socket.c:2161
     __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
     do_syscall_64+0xbe/0x100 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    
    The root cause is that we don't validate whether bear name is a valid
    string in tipc_nl_compat_bearer_enable().
    
    Meanwhile, we also fix the same issue in the following functions:
    tipc_nl_compat_bearer_disable()
    tipc_nl_compat_link_stat_dump()
    tipc_nl_compat_media_set()
    tipc_nl_compat_bearer_set()
    
    Reported-by: syzbot+b33d5cae0efd35dbfe77@syzkaller.appspotmail.com
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ad734a2b3ce31199c34910fa61718d367a6e909
Author: Ying Xue <ying.xue@windriver.com>
Date:   Mon Jan 14 17:22:25 2019 +0800

    tipc: fix uninit-value in tipc_nl_compat_link_reset_stats
    
    commit 8b66fee7f8ee18f9c51260e7a43ab37db5177a05 upstream.
    
    syzbot reports following splat:
    
    BUG: KMSAN: uninit-value in strlen+0x3b/0xa0 lib/string.c:486
    CPU: 1 PID: 11057 Comm: syz-executor0 Not tainted 4.20.0-rc7+ #2
    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+0x173/0x1d0 lib/dump_stack.c:113
     kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
     __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:295
     strlen+0x3b/0xa0 lib/string.c:486
     nla_put_string include/net/netlink.h:1154 [inline]
     tipc_nl_compat_link_reset_stats+0x1f0/0x360 net/tipc/netlink_compat.c:760
     __tipc_nl_compat_doit net/tipc/netlink_compat.c:311 [inline]
     tipc_nl_compat_doit+0x3aa/0xaf0 net/tipc/netlink_compat.c:344
     tipc_nl_compat_handle net/tipc/netlink_compat.c:1107 [inline]
     tipc_nl_compat_recv+0x14d7/0x2760 net/tipc/netlink_compat.c:1210
     genl_family_rcv_msg net/netlink/genetlink.c:601 [inline]
     genl_rcv_msg+0x185f/0x1a60 net/netlink/genetlink.c:626
     netlink_rcv_skb+0x444/0x640 net/netlink/af_netlink.c:2477
     genl_rcv+0x63/0x80 net/netlink/genetlink.c:637
     netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
     netlink_unicast+0xf40/0x1020 net/netlink/af_netlink.c:1336
     netlink_sendmsg+0x127f/0x1300 net/netlink/af_netlink.c:1917
     sock_sendmsg_nosec net/socket.c:621 [inline]
     sock_sendmsg net/socket.c:631 [inline]
     ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2116
     __sys_sendmsg net/socket.c:2154 [inline]
     __do_sys_sendmsg net/socket.c:2163 [inline]
     __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
     __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    RIP: 0033:0x457ec9
    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:00007f2557338c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457ec9
    RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003
    RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f25573396d4
    R13: 00000000004cb478 R14: 00000000004d86c8 R15: 00000000ffffffff
    
    Uninit was created at:
     kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
     kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158
     kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176
     kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185
     slab_post_alloc_hook mm/slab.h:446 [inline]
     slab_alloc_node mm/slub.c:2759 [inline]
     __kmalloc_node_track_caller+0xe18/0x1030 mm/slub.c:4383
     __kmalloc_reserve net/core/skbuff.c:137 [inline]
     __alloc_skb+0x309/0xa20 net/core/skbuff.c:205
     alloc_skb include/linux/skbuff.h:998 [inline]
     netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline]
     netlink_sendmsg+0xb82/0x1300 net/netlink/af_netlink.c:1892
     sock_sendmsg_nosec net/socket.c:621 [inline]
     sock_sendmsg net/socket.c:631 [inline]
     ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2116
     __sys_sendmsg net/socket.c:2154 [inline]
     __do_sys_sendmsg net/socket.c:2163 [inline]
     __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
     __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    
    The uninitialised access happened in tipc_nl_compat_link_reset_stats:
        nla_put_string(skb, TIPC_NLA_LINK_NAME, name)
    
    This is because name string is not validated before it's used.
    
    Reported-by: syzbot+e01d94b5a4c266be6e4c@syzkaller.appspotmail.com
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81b2fee6eb16e0f942dc921a1e1382d7c31a6722
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Jan 14 18:34:02 2019 +0800

    sctp: allocate sctp_sockaddr_entry with kzalloc
    
    commit 400b8b9a2a17918f8ce00786f596f530e7f30d50 upstream.
    
    The similar issue as fixed in Commit 4a2eb0c37b47 ("sctp: initialize
    sin6_flowinfo for ipv6 addrs in sctp_inet6addr_event") also exists
    in sctp_inetaddr_event, as Alexander noticed.
    
    To fix it, allocate sctp_sockaddr_entry with kzalloc for both sctp
    ipv4 and ipv6 addresses, as does in sctp_v4/6_copy_addrlist().
    
    Reported-by: Alexander Potapenko <glider@google.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Reported-by: syzbot+ae0c70c0c2d40c51bb92@syzkaller.appspotmail.com
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fb89795bbaea0a2c69549b78249eeecd28c721e
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jan 14 09:48:10 2019 +0100

    blockdev: Fix livelocks on loop device
    
    commit 04906b2f542c23626b0ef6219b808406f8dddbe9 upstream.
    
    bd_set_size() updates also block device's block size. This is somewhat
    unexpected from its name and at this point, only blkdev_open() uses this
    functionality. Furthermore, this can result in changing block size under
    a filesystem mounted on a loop device which leads to livelocks inside
    __getblk_gfp() like:
    
    Sending NMI from CPU 0 to CPUs 1:
    NMI backtrace for cpu 1
    CPU: 1 PID: 10863 Comm: syz-executor0 Not tainted 4.18.0-rc5+ #151
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
    01/01/2011
    RIP: 0010:__sanitizer_cov_trace_pc+0x3f/0x50 kernel/kcov.c:106
    ...
    Call Trace:
     init_page_buffers+0x3e2/0x530 fs/buffer.c:904
     grow_dev_page fs/buffer.c:947 [inline]
     grow_buffers fs/buffer.c:1009 [inline]
     __getblk_slow fs/buffer.c:1036 [inline]
     __getblk_gfp+0x906/0xb10 fs/buffer.c:1313
     __bread_gfp+0x2d/0x310 fs/buffer.c:1347
     sb_bread include/linux/buffer_head.h:307 [inline]
     fat12_ent_bread+0x14e/0x3d0 fs/fat/fatent.c:75
     fat_ent_read_block fs/fat/fatent.c:441 [inline]
     fat_alloc_clusters+0x8ce/0x16e0 fs/fat/fatent.c:489
     fat_add_cluster+0x7a/0x150 fs/fat/inode.c:101
     __fat_get_block fs/fat/inode.c:148 [inline]
    ...
    
    Trivial reproducer for the problem looks like:
    
    truncate -s 1G /tmp/image
    losetup /dev/loop0 /tmp/image
    mkfs.ext4 -b 1024 /dev/loop0
    mount -t ext4 /dev/loop0 /mnt
    losetup -c /dev/loop0
    l /mnt
    
    Fix the problem by moving initialization of a block device block size
    into a separate function and call it when needed.
    
    Thanks to Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> for help with
    debugging the problem.
    
    Reported-by: syzbot+9933e4476f365f5d5a1b@syzkaller.appspotmail.com
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 484636b44424008464636f713424a79bd7be5265
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Wed Jan 9 10:55:10 2019 -0500

    selinux: fix GPF on invalid policy
    
    commit 5b0e7310a2a33c06edc7eb81ffc521af9b2c5610 upstream.
    
    levdatum->level can be NULL if we encounter an error while loading
    the policy during sens_read prior to initializing it.  Make sure
    sens_destroy handles that case correctly.
    
    Reported-by: syzbot+6664500f0f18f07a5c0e@syzkaller.appspotmail.com
    Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26e6d521e5520d62f72fc5682e87bd0bcdbc5b66
Author: Shakeel Butt <shakeelb@google.com>
Date:   Wed Jan 2 19:14:31 2019 -0800

    netfilter: ebtables: account ebt_table_info to kmemcg
    
    commit e2c8d550a973bb34fc28bc8d0ec996f84562fb8a upstream.
    
    The [ip,ip6,arp]_tables use x_tables_info internally and the underlying
    memory is already accounted to kmemcg. Do the same for ebtables. The
    syzbot, by using setsockopt(EBT_SO_SET_ENTRIES), was able to OOM the
    whole system from a restricted memcg, a potential DoS.
    
    By accounting the ebt_table_info, the memory used for ebt_table_info can
    be contained within the memcg of the allocating process. However the
    lifetime of ebt_table_info is independent of the allocating process and
    is tied to the network namespace. So, the oom-killer will not be able to
    relieve the memory pressure due to ebt_table_info memory. The memory for
    ebt_table_info is allocated through vmalloc. Currently vmalloc does not
    handle the oom-killed allocating process correctly and one large
    allocation can bypass memcg limit enforcement. So, with this patch,
    at least the small allocations will be contained. For large allocations,
    we need to fix vmalloc.
    
    Reported-by: syzbot+7713f3aa67be76b1552c@syzkaller.appspotmail.com
    Signed-off-by: Shakeel Butt <shakeelb@google.com>
    Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f85592f4c0cb6c6b99e6e4fcd1701fa19d79c587
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Dec 20 10:35:11 2018 -0500

    sunrpc: handle ENOMEM in rpcb_getport_async
    
    commit 81c88b18de1f11f70c97f28ced8d642c00bb3955 upstream.
    
    If we ignore the error we'll hit a null dereference a little later.
    
    Reported-by: syzbot+4b98281f2401ab849f4b@syzkaller.appspotmail.com
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb376a62ac5d0ad2d0b98e9ca6eeb71e2efa53ac
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Tue Nov 13 09:06:46 2018 -0500

    media: vb2: vb2_mmap: move lock up
    
    commit cd26d1c4d1bc947b56ae404998ae2276df7b39b7 upstream.
    
    If a filehandle is dup()ped, then it is possible to close it from one fd
    and call mmap from the other. This creates a race condition in vb2_mmap
    where it is using queue data that __vb2_queue_free (called from close())
    is in the process of releasing.
    
    By moving up the mutex_lock(mmap_lock) in vb2_mmap this race is avoided
    since __vb2_queue_free is called with the same mutex locked. So vb2_mmap
    now reads consistent buffer data.
    
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Reported-by: syzbot+be93025dd45dccd8923c@syzkaller.appspotmail.com
    Signed-off-by: Hans Verkuil <hansverk@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9f9379336425ebd0c07d454857ddbc6fe750b36
Author: James Morris <james.morris@microsoft.com>
Date:   Wed Jan 16 15:41:11 2019 -0800

    LSM: Check for NULL cred-security on free
    
    commit a5795fd38ee8194451ba3f281f075301a3696ce2 upstream.
    
    From: Casey Schaufler <casey@schaufler-ca.com>
    
    Check that the cred security blob has been set before trying
    to clean it up. There is a case during credential initialization
    that could result in this.
    
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Acked-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: James Morris <james.morris@microsoft.com>
    Reported-by: syzbot+69ca07954461f189e808@syzkaller.appspotmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 993e65a624c038561a57cbf5d28f087005b4df86
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Jan 15 20:19:22 2019 -0500

    bpf: in __bpf_redirect_no_mac pull mac only if present
    
    commit e7c87bd6cc4ec7b0ac1ed0a88a58f8206c577488 upstream.
    
    Syzkaller was able to construct a packet of negative length by
    redirecting from bpf_prog_test_run_skb with BPF_PROG_TYPE_LWT_XMIT:
    
        BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:345 [inline]
        BUG: KASAN: slab-out-of-bounds in skb_copy_from_linear_data include/linux/skbuff.h:3421 [inline]
        BUG: KASAN: slab-out-of-bounds in __pskb_copy_fclone+0x2dd/0xeb0 net/core/skbuff.c:1395
        Read of size 4294967282 at addr ffff8801d798009c by task syz-executor2/12942
    
        kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
        check_memory_region_inline mm/kasan/kasan.c:260 [inline]
        check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
        memcpy+0x23/0x50 mm/kasan/kasan.c:302
        memcpy include/linux/string.h:345 [inline]
        skb_copy_from_linear_data include/linux/skbuff.h:3421 [inline]
        __pskb_copy_fclone+0x2dd/0xeb0 net/core/skbuff.c:1395
        __pskb_copy include/linux/skbuff.h:1053 [inline]
        pskb_copy include/linux/skbuff.h:2904 [inline]
        skb_realloc_headroom+0xe7/0x120 net/core/skbuff.c:1539
        ipip6_tunnel_xmit net/ipv6/sit.c:965 [inline]
        sit_tunnel_xmit+0xe1b/0x30d0 net/ipv6/sit.c:1029
        __netdev_start_xmit include/linux/netdevice.h:4325 [inline]
        netdev_start_xmit include/linux/netdevice.h:4334 [inline]
        xmit_one net/core/dev.c:3219 [inline]
        dev_hard_start_xmit+0x295/0xc90 net/core/dev.c:3235
        __dev_queue_xmit+0x2f0d/0x3950 net/core/dev.c:3805
        dev_queue_xmit+0x17/0x20 net/core/dev.c:3838
        __bpf_tx_skb net/core/filter.c:2016 [inline]
        __bpf_redirect_common net/core/filter.c:2054 [inline]
        __bpf_redirect+0x5cf/0xb20 net/core/filter.c:2061
        ____bpf_clone_redirect net/core/filter.c:2094 [inline]
        bpf_clone_redirect+0x2f6/0x490 net/core/filter.c:2066
        bpf_prog_41f2bcae09cd4ac3+0xb25/0x1000
    
    The generated test constructs a packet with mac header, network
    header, skb->data pointing to network header and skb->len 0.
    
    Redirecting to a sit0 through __bpf_redirect_no_mac pulls the
    mac length, even though skb->data already is at skb->network_header.
    bpf_prog_test_run_skb has already pulled it as LWT_XMIT !is_l2.
    
    Update the offset calculation to pull only if skb->data differs
    from skb->network_header, which is not true in this case.
    
    The test itself can be run only from commit 1cf1cae963c2 ("bpf:
    introduce BPF_PROG_TEST_RUN command"), but the same type of packets
    with skb at network header could already be built from lwt xmit hooks,
    so this fix is more relevant to that commit.
    
    Also set the mac header on redirect from LWT_XMIT, as even after this
    change to __bpf_redirect_no_mac that field is expected to be set, but
    is not yet in ip_finish_output2.
    
    Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 254cb979105da1b59ec3b99dd0156a43e9989194
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Mon Oct 29 13:32:38 2018 -0400

    media: vivid: set min width/height to a value > 0
    
    commit 9729d6d282a6d7ce88e64c9119cecdf79edf4e88 upstream.
    
    The capture DV timings capabilities allowed for a minimum width and
    height of 0. So passing a timings struct with 0 values is allowed
    and will later cause a division by zero.
    
    Ensure that the width and height must be >= 16 to avoid this.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: syzbot+57c3d83d71187054d56f@syzkaller.appspotmail.com
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b25a1cfe95ff15a302975f2b2824387b23b81d1
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Mon Oct 29 06:15:31 2018 -0400

    media: vivid: fix error handling of kthread_run
    
    commit 701f49bc028edb19ffccd101997dd84f0d71e279 upstream.
    
    kthread_run returns an error pointer, but elsewhere in the code
    dev->kthread_vid_cap/out is checked against NULL.
    
    If kthread_run returns an error, then set the pointer to NULL.
    
    I chose this method over changing all kthread_vid_cap/out tests
    elsewhere since this is more robust.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: syzbot+53d5b2df0d9744411e2e@syzkaller.appspotmail.com
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9171634695140ea811b0030f5d208d8798153c56
Author: Vlad Tsyrklevich <vlad@tsyrklevich.net>
Date:   Fri Jan 11 14:34:38 2019 +0100

    omap2fb: Fix stack memory disclosure
    
    commit a01421e4484327fe44f8e126793ed5a48a221e24 upstream.
    
    Using [1] for static analysis I found that the OMAPFB_QUERY_PLANE,
    OMAPFB_GET_COLOR_KEY, OMAPFB_GET_DISPLAY_INFO, and OMAPFB_GET_VRAM_INFO
    cases could all leak uninitialized stack memory--either due to
    uninitialized padding or 'reserved' fields.
    
    Fix them by clearing the shared union used to store copied out data.
    
    [1] https://github.com/vlad902/kernel-uninitialized-memory-checker
    
    Signed-off-by: Vlad Tsyrklevich <vlad@tsyrklevich.net>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Fixes: b39a982ddecf ("OMAP: DSS2: omapfb driver")
    Cc: security@kernel.org
    [b.zolnierkie: prefix patch subject with "omap2fb: "]
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c79a6a8ed98ba7efc80f6dd6e729750147e2e2e
Author: YunQiang Su <ysu@wavecomp.com>
Date:   Tue Jan 8 13:45:10 2019 +0800

    Disable MSI also when pcie-octeon.pcie_disable on
    
    commit a214720cbf50cd8c3f76bbb9c3f5c283910e9d33 upstream.
    
    Octeon has an boot-time option to disable pcie.
    
    Since MSI depends on PCI-E, we should also disable MSI also with
    this option is on in order to avoid inadvertently accessing PCIe
    registers.
    
    Signed-off-by: YunQiang Su <ysu@wavecomp.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: pburton@wavecomp.com
    Cc: linux-mips@vger.kernel.org
    Cc: aaro.koskinen@iki.fi
    Cc: stable@vger.kernel.org # v3.3+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee624c01973b4cbc56eecac96bf1a72790d3addf
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Tue Jan 15 20:47:07 2019 +0100

    arm64: kaslr: ensure randomized quantities are clean to the PoC
    
    commit 1598ecda7b239e9232dda032bfddeed9d89fab6c upstream.
    
    kaslr_early_init() is called with the kernel mapped at its
    link time offset, and if it returns with a non-zero offset,
    the kernel is unmapped and remapped again at the randomized
    offset.
    
    During its execution, kaslr_early_init() also randomizes the
    base of the module region and of the linear mapping of DRAM,
    and sets two variables accordingly. However, since these
    variables are assigned with the caches on, they may get lost
    during the cache maintenance that occurs when unmapping and
    remapping the kernel, so ensure that these values are cleaned
    to the PoC.
    
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR")
    Cc: <stable@vger.kernel.org> # v4.6+
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96188b18861a78efb40d390931cbe8d938d6a3cb
Author: Kees Cook <keescook@chromium.org>
Date:   Sun Jan 20 14:33:34 2019 -0800

    pstore/ram: Avoid allocation and leak of platform data
    
    commit 5631e8576a3caf606cdc375f97425a67983b420c upstream.
    
    Yue Hu noticed that when parsing device tree the allocated platform data
    was never freed. Since it's not used beyond the function scope, this
    switches to using a stack variable instead.
    
    Reported-by: Yue Hu <huyue2@yulong.com>
    Fixes: 35da60941e44 ("pstore/ram: add Device Tree bindings")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71a41c7d322f72d6cecc972ae1e112dae8790470
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Jan 10 09:24:26 2019 -0500

    media: v4l: ioctl: Validate num_planes for debug messages
    
    commit 7fe9f01c04c2673bd6662c35b664f0f91888b96f upstream.
    
    The num_planes field in struct v4l2_pix_format_mplane is used in a loop
    before validating it. As the use is printing a debug message in this case,
    just cap the value to the maximum allowed.
    
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Cc: <stable@vger.kernel.org>      # for v4.12 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 501f37b68703b09bfaaaa2b5196f58d7a80ca3f9
Author: Jonathan Hunter <jonathanh@nvidia.com>
Date:   Tue Nov 13 08:56:31 2018 +0000

    mfd: tps6586x: Handle interrupts on suspend
    
    commit ac4ca4b9f4623ba5e1ea7a582f286567c611e027 upstream.
    
    The tps6586x driver creates an irqchip that is used by its various child
    devices for managing interrupts. The tps6586x-rtc device is one of its
    children that uses the tps6586x irqchip. When using the tps6586x-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.
     OOM killer disabled.
     Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
     Disabling non-boot CPUs ...
     Entering suspend state LP1
     Enabling non-boot CPUs ...
     CPU1 is up
     tps6586x 3-0034: failed to read interrupt status
     tps6586x 3-0034: failed to read interrupt status
    
    The reason why the tps6586x interrupt status cannot be read is because
    the tps6586x interrupt is not masked during suspend and when the
    tps6586x-rtc interrupt occurs, to wake-up the device, the interrupt is
    seen before the i2c controller has been resumed in order to read the
    tps6586x interrupt status.
    
    The tps6586x-rtc driver sets it's interrupt as a wake-up source during
    suspend, which gets propagated to the parent tps6586x interrupt.
    However, the tps6586x-rtc driver cannot disable it's interrupt during
    suspend otherwise we would never be woken up and so the tps6586x must
    disable it's interrupt instead.
    
    Prevent the tps6586x interrupt handler from executing on exiting suspend
    before the i2c controller has been resumed by disabling the tps6586x
    interrupt on entering suspend and re-enabling it on resuming from
    suspend.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
    Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
    Tested-by: Dmitry Osipenko <digetx@gmail.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7c0d6db36380165a4f1586c874dbb09285c933f
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Sun Jan 13 10:44:50 2019 +0100

    OF: properties: add missing of_node_put
    
    commit 28b170e88bc0c7509e6724717c15cb4b5686026e upstream.
    
    Add an of_node_put when the result of of_graph_get_remote_port_parent is
    not available.
    
    The semantic match that finds this problem is as follows
    (http://coccinelle.lip6.fr):
    
    // <smpl>
    @r exists@
    local idexpression e;
    expression x;
    @@
    e = of_graph_get_remote_port_parent(...);
    ... when != x = e
        when != true e == NULL
        when != of_node_put(e)
        when != of_fwnode_handle(e)
    (
    return e;
    |
    *return ...;
    )
    // </smpl>
    
    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    Cc: stable@vger.kernel.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a06d94d98d2417510ab2dab39f633d6557b0bb68
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Sun Jan 6 19:44:11 2019 +0100

    MIPS: lantiq: Fix IPI interrupt handling
    
    commit 2b4dba55b04b212a7fd1f0395b41d79ee3a9801b upstream.
    
    This makes SMP on the vrx200 work again, by removing all the MIPS CPU
    interrupt specific code and making it fully use the generic MIPS CPU
    interrupt controller.
    
    The mti,cpu-interrupt-controller from irq-mips-cpu.c now handles the CPU
    interrupts and also the IPI interrupts which are used to communication
    between the CPUs in a SMP system. The generic interrupt code was
    already used before but the interrupt vectors were overwritten again
    when we called set_vi_handler() in the lantiq interrupt driver and we
    also provided our own plat_irq_dispatch() function which overwrote the
    weak generic implementation. Now the code uses the generic handler for
    the MIPS CPU interrupts including the IPI interrupts and registers a
    handler for the CPU interrupts which are handled by the lantiq ICU with
    irq_set_chained_handler() which was already called before.
    
    Calling the set_c0_status() function is also not needed any more because
    the generic MIPS CPU interrupt already activates the needed bits.
    
    Fixes: 1eed40043579 ("MIPS: smp-mt: Use CPU interrupt controller IPI IRQ domain support")
    Cc: stable@kernel.org # v4.12
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: jhogan@kernel.org
    Cc: ralf@linux-mips.org
    Cc: john@phrozen.org
    Cc: linux-mips@linux-mips.org
    Cc: linux-mips@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb2fb7b7c4dcbd3399cb3988642ee2d7b32f2b73
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Jan 10 17:24:31 2019 +0100

    mips: fix n32 compat_ipc_parse_version
    
    commit 5a9372f751b5350e0ce3d2ee91832f1feae2c2e5 upstream.
    
    While reading through the sysvipc implementation, I noticed that the n32
    semctl/shmctl/msgctl system calls behave differently based on whether
    o32 support is enabled or not: Without o32, the IPC_64 flag passed by
    user space is rejected but calls without that flag get IPC_64 behavior.
    
    As far as I can tell, this was inadvertently changed by a cleanup patch
    but never noticed by anyone, possibly nobody has tried using sysvipc
    on n32 after linux-3.19.
    
    Change it back to the old behavior now.
    
    Fixes: 78aaf956ba3a ("MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: linux-mips@vger.kernel.org
    Cc: stable@vger.kernel.org # 3.19+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8041d33bf8d515969a11efa8b39febde918bbc9d
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Tue Jan 8 06:56:48 2019 +0000

    crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK
    
    commit 1bea445b0a022ee126ca328b3705cd4df18ebc14 upstream.
    
    [    2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837 dma_nommu_map_page+0x44/0xd4
    [    2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: G        W         4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
    [    2.384740] NIP:  c000c540 LR: c000c584 CTR: 00000000
    [    2.389743] REGS: c95abab0 TRAP: 0700   Tainted: G        W          (4.20.0-rc5-00560-g6bfb52e23a00-dirty)
    [    2.400042] MSR:  00029032 <EE,ME,IR,DR,RI>  CR: 24042204  XER: 00000000
    [    2.406669]
    [    2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 0000256a 00000001 00000001 00000001
    [    2.406669] GPR08: 00000000 00002000 00000010 00000010 24042202 00000000 00000100 c95abd88
    [    2.406669] GPR16: 00000000 c05569d4 00000001 00000010 c95abc88 c0615664 00000004 00000000
    [    2.406669] GPR24: 00000010 c95abc88 c95abc88 00000000 c61ae210 c7ff6d40 c61ae210 00003d68
    [    2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4
    [    2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4
    [    2.451762] Call Trace:
    [    2.454195] [c95abb60] [82000808] 0x82000808 (unreliable)
    [    2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8
    [    2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c
    [    2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64
    [    2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08
    [    2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc
    [    2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc
    [    2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8
    [    2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50
    [    2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110
    [    2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
    [    2.515532] Instruction dump:
    [    2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076 7c84e850
    [    2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe00000> 2f9e0000 54847022 7c84fa14
    [    2.533960] ---[ end trace bf78d94af73fe3b8 ]---
    [    2.539123] talitos ff020000.crypto: master data transfer error
    [    2.544775] talitos ff020000.crypto: TEA error: ISR 0x20000000_00000040
    [    2.551625] alg: skcipher: encryption failed on test 1 for ecb-aes-talitos: ret=22
    
    IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
    cannot be DMA mapped anymore.
    
    This patch copies the IV into the extended descriptor.
    
    Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3f5e4efce3e2ece7f31826a14849e60d342bde1
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Tue Jan 8 06:56:46 2019 +0000

    crypto: talitos - reorder code in talitos_edesc_alloc()
    
    commit c56c2e173773097a248fd3bace91ac8f6fc5386d upstream.
    
    This patch moves the mapping of IV after the kmalloc(). This
    avoids having to unmap in case kmalloc() fails.
    
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24c99a924db92c46cb317856e7e84c61ff02c8cb
Author: Ivan Mironov <mironov.ivan@gmail.com>
Date:   Sun Dec 23 12:41:58 2018 +0500

    scsi: sd: Fix cache_type_store()
    
    commit 44759979a49bfd2d20d789add7fa81a21eb1a4ab upstream.
    
    Changing of caching mode via /sys/devices/.../scsi_disk/.../cache_type may
    fail if device responds to MODE SENSE command with DPOFUA flag set, and
    then checks this flag to be not set on MODE SELECT command.
    
    In this scenario, when trying to change cache_type, write always fails:
    
            # echo "none" >cache_type
            bash: echo: write error: Invalid argument
    
    And following appears in dmesg:
    
            [13007.865745] sd 1:0:1:0: [sda] Sense Key : Illegal Request [current]
            [13007.865753] sd 1:0:1:0: [sda] Add. Sense: Invalid field in parameter list
    
    From SBC-4 r15, 6.5.1 "Mode pages overview", description of DEVICE-SPECIFIC
    PARAMETER field in the mode parameter header:
            ...
            The write protect (WP) bit for mode data sent with a MODE SELECT
            command shall be ignored by the device server.
            ...
            The DPOFUA bit is reserved for mode data sent with a MODE SELECT
            command.
            ...
    
    The remaining bits in the DEVICE-SPECIFIC PARAMETER byte are also reserved
    and shall be set to zero.
    
    [mkp: shuffled commentary to commit description]
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit caae28b3ae154a5380ff647c80ec5d9818ea61f0
Author: Stanley Chu <stanley.chu@mediatek.com>
Date:   Thu Jan 3 22:08:05 2019 +0800

    scsi: core: Synchronize request queue PM status only on successful resume
    
    commit 3f7e62bba0003f9c68f599f5997c4647ef5b4f4e upstream.
    
    The commit 356fd2663cff ("scsi: Set request queue runtime PM status back to
    active on resume") fixed up the inconsistent RPM status between request
    queue and device. However changing request queue RPM status shall be done
    only on successful resume, otherwise status may be still inconsistent as
    below,
    
    Request queue: RPM_ACTIVE
    Device: RPM_SUSPENDED
    
    This ends up soft lockup because requests can be submitted to underlying
    devices but those devices and their required resource are not resumed.
    
    For example,
    
    After above inconsistent status happens, IO request can be submitted to UFS
    device driver but required resource (like clock) is not resumed yet thus
    lead to warning as below call stack,
    
    WARN_ON(hba->clk_gating.state != CLKS_ON);
    ufshcd_queuecommand
    scsi_dispatch_cmd
    scsi_request_fn
    __blk_run_queue
    cfq_insert_request
    __elv_add_request
    blk_flush_plug_list
    blk_finish_plug
    jbd2_journal_commit_transaction
    kjournald2
    
    We may see all behind IO requests hang because of no response from storage
    host or device and then soft lockup happens in system. In the end, system
    may crash in many ways.
    
    Fixes: 356fd2663cff (scsi: Set request queue runtime PM status back to active on resume)
    Cc: stable@vger.kernel.org
    Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41c13bfcc4cdeac537c060a5156a688c69d9c6a5
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jan 16 10:31:09 2019 -0800

    Yama: Check for pid death before checking ancestry
    
    commit 9474f4e7cd71a633fa1ef93b7daefd44bbdfd482 upstream.
    
    It's possible that a pid has died before we take the rcu lock, in which
    case we can't walk the ancestry list as it may be detached. Instead, check
    for death first before doing the walk.
    
    Reported-by: syzbot+a9ac39bf55329e206219@syzkaller.appspotmail.com
    Fixes: 2d514487faf1 ("security: Yama LSM")
    Cc: stable@vger.kernel.org
    Suggested-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: James Morris <james.morris@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f97fd2926eed63bd5141261e00f027b2ba3b6661
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Nov 21 14:05:45 2018 -0500

    btrfs: wait on ordered extents on abort cleanup
    
    commit 74d5d229b1bf60f93bff244b2dfc0eb21ec32a07 upstream.
    
    If we flip read-only before we initiate writeback on all dirty pages for
    ordered extents we've created then we'll have ordered extents left over
    on umount, which results in all sorts of bad things happening.  Fix this
    by making sure we wait on ordered extents if we have to do the aborted
    transaction cleanup stuff.
    
    generic/475 can produce this warning:
    
     [ 8531.177332] WARNING: CPU: 2 PID: 11997 at fs/btrfs/disk-io.c:3856 btrfs_free_fs_root+0x95/0xa0 [btrfs]
     [ 8531.183282] CPU: 2 PID: 11997 Comm: umount Tainted: G        W 5.0.0-rc1-default+ #394
     [ 8531.185164] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014
     [ 8531.187851] RIP: 0010:btrfs_free_fs_root+0x95/0xa0 [btrfs]
     [ 8531.193082] RSP: 0018:ffffb1ab86163d98 EFLAGS: 00010286
     [ 8531.194198] RAX: ffff9f3449494d18 RBX: ffff9f34a2695000 RCX:0000000000000000
     [ 8531.195629] RDX: 0000000000000002 RSI: 0000000000000001 RDI:0000000000000000
     [ 8531.197315] RBP: ffff9f344e930000 R08: 0000000000000001 R09:0000000000000000
     [ 8531.199095] R10: 0000000000000000 R11: ffff9f34494d4ff8 R12:ffffb1ab86163dc0
     [ 8531.200870] R13: ffff9f344e9300b0 R14: ffffb1ab86163db8 R15:0000000000000000
     [ 8531.202707] FS:  00007fc68e949fc0(0000) GS:ffff9f34bd800000(0000)knlGS:0000000000000000
     [ 8531.204851] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     [ 8531.205942] CR2: 00007ffde8114dd8 CR3: 000000002dfbd000 CR4:00000000000006e0
     [ 8531.207516] Call Trace:
     [ 8531.208175]  btrfs_free_fs_roots+0xdb/0x170 [btrfs]
     [ 8531.210209]  ? wait_for_completion+0x5b/0x190
     [ 8531.211303]  close_ctree+0x157/0x350 [btrfs]
     [ 8531.212412]  generic_shutdown_super+0x64/0x100
     [ 8531.213485]  kill_anon_super+0x14/0x30
     [ 8531.214430]  btrfs_kill_super+0x12/0xa0 [btrfs]
     [ 8531.215539]  deactivate_locked_super+0x29/0x60
     [ 8531.216633]  cleanup_mnt+0x3b/0x70
     [ 8531.217497]  task_work_run+0x98/0xc0
     [ 8531.218397]  exit_to_usermode_loop+0x83/0x90
     [ 8531.219324]  do_syscall_64+0x15b/0x180
     [ 8531.220192]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
     [ 8531.221286] RIP: 0033:0x7fc68e5e4d07
     [ 8531.225621] RSP: 002b:00007ffde8116608 EFLAGS: 00000246 ORIG_RAX:00000000000000a6
     [ 8531.227512] RAX: 0000000000000000 RBX: 00005580c2175970 RCX:00007fc68e5e4d07
     [ 8531.229098] RDX: 0000000000000001 RSI: 0000000000000000 RDI:00005580c2175b80
     [ 8531.230730] RBP: 0000000000000000 R08: 00005580c2175ba0 R09:00007ffde8114e80
     [ 8531.232269] R10: 0000000000000000 R11: 0000000000000246 R12:00005580c2175b80
     [ 8531.233839] R13: 00007fc68eac61c4 R14: 00005580c2175a68 R15:0000000000000000
    
    Leaving a tree in the rb-tree:
    
    3853 void btrfs_free_fs_root(struct btrfs_root *root)
    3854 {
    3855         iput(root->ino_cache_inode);
    3856         WARN_ON(!RB_EMPTY_ROOT(&root->inode_tree));
    
    CC: stable@vger.kernel.org
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    [ add stacktrace ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0400be165676222b825e064f973d7397fee943b5
Author: David Sterba <dsterba@suse.com>
Date:   Wed Jan 9 15:02:23 2019 +0100

    Revert "btrfs: balance dirty metadata pages in btrfs_finish_ordered_io"
    
    commit 77b7aad195099e7c6da11e94b7fa6ef5e6fb0025 upstream.
    
    This reverts commit e73e81b6d0114d4a303205a952ab2e87c44bd279.
    
    This patch causes a few problems:
    
    - adds latency to btrfs_finish_ordered_io
    - as btrfs_finish_ordered_io is used for free space cache, generating
      more work from btrfs_btree_balance_dirty_nodelay could end up in the
      same workque, effectively deadlocking
    
    12260 kworker/u96:16+btrfs-freespace-write D
    [<0>] balance_dirty_pages+0x6e6/0x7ad
    [<0>] balance_dirty_pages_ratelimited+0x6bb/0xa90
    [<0>] btrfs_finish_ordered_io+0x3da/0x770
    [<0>] normal_work_helper+0x1c5/0x5a0
    [<0>] process_one_work+0x1ee/0x5a0
    [<0>] worker_thread+0x46/0x3d0
    [<0>] kthread+0xf5/0x130
    [<0>] ret_from_fork+0x24/0x30
    [<0>] 0xffffffffffffffff
    
    Transaction commit will wait on the freespace cache:
    
    838 btrfs-transacti D
    [<0>] btrfs_start_ordered_extent+0x154/0x1e0
    [<0>] btrfs_wait_ordered_range+0xbd/0x110
    [<0>] __btrfs_wait_cache_io+0x49/0x1a0
    [<0>] btrfs_write_dirty_block_groups+0x10b/0x3b0
    [<0>] commit_cowonly_roots+0x215/0x2b0
    [<0>] btrfs_commit_transaction+0x37e/0x910
    [<0>] transaction_kthread+0x14d/0x180
    [<0>] kthread+0xf5/0x130
    [<0>] ret_from_fork+0x24/0x30
    [<0>] 0xffffffffffffffff
    
    And then writepages ends up waiting on transaction commit:
    
    9520 kworker/u96:13+flush-btrfs-1 D
    [<0>] wait_current_trans+0xac/0xe0
    [<0>] start_transaction+0x21b/0x4b0
    [<0>] cow_file_range_inline+0x10b/0x6b0
    [<0>] cow_file_range.isra.69+0x329/0x4a0
    [<0>] run_delalloc_range+0x105/0x3c0
    [<0>] writepage_delalloc+0x119/0x180
    [<0>] __extent_writepage+0x10c/0x390
    [<0>] extent_write_cache_pages+0x26f/0x3d0
    [<0>] extent_writepages+0x4f/0x80
    [<0>] do_writepages+0x17/0x60
    [<0>] __writeback_single_inode+0x59/0x690
    [<0>] writeback_sb_inodes+0x291/0x4e0
    [<0>] __writeback_inodes_wb+0x87/0xb0
    [<0>] wb_writeback+0x3bb/0x500
    [<0>] wb_workfn+0x40d/0x610
    [<0>] process_one_work+0x1ee/0x5a0
    [<0>] worker_thread+0x1e0/0x3d0
    [<0>] kthread+0xf5/0x130
    [<0>] ret_from_fork+0x24/0x30
    [<0>] 0xffffffffffffffff
    
    Eventually, we have every process in the system waiting on
    balance_dirty_pages(), and nobody is able to make progress on page
    writeback.
    
    The original patch tried to fix an OOM condition, that happened on 4.4 but no
    success reproducing that on later kernels (4.19 and 4.20). This is more likely
    a problem in OOM itself.
    
    Link: https://lore.kernel.org/linux-btrfs/20180528054821.9092-1-ethanlien@synology.com/
    Reported-by: Chris Mason <clm@fb.com>
    CC: stable@vger.kernel.org # 4.18+
    CC: ethanlien <ethanlien@synology.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9119fd2749c1459416ebb559cf7c1d379786cff
Author: Eric Biggers <ebiggers@google.com>
Date:   Sun Dec 16 23:23:22 2018 -0800

    crypto: authenc - fix parsing key with misaligned rta_len
    
    commit 8f9c469348487844328e162db57112f7d347c49f upstream.
    
    Keys for "authenc" AEADs are formatted as an rtattr containing a 4-byte
    'enckeylen', followed by an authentication key and an encryption key.
    crypto_authenc_extractkeys() parses the key to find the inner keys.
    
    However, it fails to consider the case where the rtattr's payload is
    longer than 4 bytes but not 4-byte aligned, and where the key ends
    before the next 4-byte aligned boundary.  In this case, 'keylen -=
    RTA_ALIGN(rta->rta_len);' underflows to a value near UINT_MAX.  This
    causes a buffer overread and crash during crypto_ahash_setkey().
    
    Fix it by restricting the rtattr payload to the expected size.
    
    Reproducer using AF_ALG:
    
            #include <linux/if_alg.h>
            #include <linux/rtnetlink.h>
            #include <sys/socket.h>
    
            int main()
            {
                    int fd;
                    struct sockaddr_alg addr = {
                            .salg_type = "aead",
                            .salg_name = "authenc(hmac(sha256),cbc(aes))",
                    };
                    struct {
                            struct rtattr attr;
                            __be32 enckeylen;
                            char keys[1];
                    } __attribute__((packed)) key = {
                            .attr.rta_len = sizeof(key),
                            .attr.rta_type = 1 /* CRYPTO_AUTHENC_KEYA_PARAM */,
                    };
    
                    fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
                    bind(fd, (void *)&addr, sizeof(addr));
                    setsockopt(fd, SOL_ALG, ALG_SET_KEY, &key, sizeof(key));
            }
    
    It caused:
    
            BUG: unable to handle kernel paging request at ffff88007ffdc000
            PGD 2e01067 P4D 2e01067 PUD 2e04067 PMD 2e05067 PTE 0
            Oops: 0000 [#1] SMP
            CPU: 0 PID: 883 Comm: authenc Not tainted 4.20.0-rc1-00108-g00c9fe37a7f27 #13
            Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014
            RIP: 0010:sha256_ni_transform+0xb3/0x330 arch/x86/crypto/sha256_ni_asm.S:155
            [...]
            Call Trace:
             sha256_ni_finup+0x10/0x20 arch/x86/crypto/sha256_ssse3_glue.c:321
             crypto_shash_finup+0x1a/0x30 crypto/shash.c:178
             shash_digest_unaligned+0x45/0x60 crypto/shash.c:186
             crypto_shash_digest+0x24/0x40 crypto/shash.c:202
             hmac_setkey+0x135/0x1e0 crypto/hmac.c:66
             crypto_shash_setkey+0x2b/0xb0 crypto/shash.c:66
             shash_async_setkey+0x10/0x20 crypto/shash.c:223
             crypto_ahash_setkey+0x2d/0xa0 crypto/ahash.c:202
             crypto_authenc_setkey+0x68/0x100 crypto/authenc.c:96
             crypto_aead_setkey+0x2a/0xc0 crypto/aead.c:62
             aead_setkey+0xc/0x10 crypto/algif_aead.c:526
             alg_setkey crypto/af_alg.c:223 [inline]
             alg_setsockopt+0xfe/0x130 crypto/af_alg.c:256
             __sys_setsockopt+0x6d/0xd0 net/socket.c:1902
             __do_sys_setsockopt net/socket.c:1913 [inline]
             __se_sys_setsockopt net/socket.c:1910 [inline]
             __x64_sys_setsockopt+0x1f/0x30 net/socket.c:1910
             do_syscall_64+0x4a/0x180 arch/x86/entry/common.c:290
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fixes: e236d4a89a2f ("[CRYPTO] authenc: Move enckeylen into key itself")
    Cc: <stable@vger.kernel.org> # v2.6.25+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c5f00e8984f8921d3a20afd04fcd0f24096b2bf
Author: Eric Biggers <ebiggers@google.com>
Date:   Sun Dec 16 23:23:23 2018 -0800

    crypto: bcm - convert to use crypto_authenc_extractkeys()
    
    commit ab57b33525c3221afaebd391458fa0cbcd56903d upstream.
    
    Convert the bcm crypto driver to use crypto_authenc_extractkeys() so
    that it picks up the fix for broken validation of rtattr::rta_len.
    
    This also fixes the DES weak key check to actually be done on the right
    key. (It was checking the authentication key, not the encryption key...)
    
    Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
    Cc: <stable@vger.kernel.org> # v4.11+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d196d2fdc0e8a0f1db9a64d0e691f7e2cd756e28
Author: Harsh Jain <harsh@chelsio.com>
Date:   Thu Jan 3 14:21:05 2019 +0530

    crypto: authencesn - Avoid twice completion call in decrypt path
    
    commit a7773363624b034ab198c738661253d20a8055c2 upstream.
    
    Authencesn template in decrypt path unconditionally calls aead_request_complete
    after ahash_verify which leads to following kernel panic in after decryption.
    
    [  338.539800] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
    [  338.548372] PGD 0 P4D 0
    [  338.551157] Oops: 0000 [#1] SMP PTI
    [  338.554919] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Tainted: G        W I       4.19.7+ #13
    [  338.564431] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0        07/29/10
    [  338.572212] RIP: 0010:esp_input_done2+0x350/0x410 [esp4]
    [  338.578030] Code: ff 0f b6 68 10 48 8b 83 c8 00 00 00 e9 8e fe ff ff 8b 04 25 04 00 00 00 83 e8 01 48 98 48 8b 3c c5 10 00 00 00 e9 f7 fd ff ff <8b> 04 25 04 00 00 00 83 e8 01 48 98 4c 8b 24 c5 10 00 00 00 e9 3b
    [  338.598547] RSP: 0018:ffff911c97803c00 EFLAGS: 00010246
    [  338.604268] RAX: 0000000000000002 RBX: ffff911c4469ee00 RCX: 0000000000000000
    [  338.612090] RDX: 0000000000000000 RSI: 0000000000000130 RDI: ffff911b87c20400
    [  338.619874] RBP: 0000000000000000 R08: ffff911b87c20498 R09: 000000000000000a
    [  338.627610] R10: 0000000000000001 R11: 0000000000000004 R12: 0000000000000000
    [  338.635402] R13: ffff911c89590000 R14: ffff911c91730000 R15: 0000000000000000
    [  338.643234] FS:  0000000000000000(0000) GS:ffff911c97800000(0000) knlGS:0000000000000000
    [  338.652047] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  338.658299] CR2: 0000000000000004 CR3: 00000001ec20a000 CR4: 00000000000006f0
    [  338.666382] Call Trace:
    [  338.669051]  <IRQ>
    [  338.671254]  esp_input_done+0x12/0x20 [esp4]
    [  338.675922]  chcr_handle_resp+0x3b5/0x790 [chcr]
    [  338.680949]  cpl_fw6_pld_handler+0x37/0x60 [chcr]
    [  338.686080]  chcr_uld_rx_handler+0x22/0x50 [chcr]
    [  338.691233]  uldrx_handler+0x8c/0xc0 [cxgb4]
    [  338.695923]  process_responses+0x2f0/0x5d0 [cxgb4]
    [  338.701177]  ? bitmap_find_next_zero_area_off+0x3a/0x90
    [  338.706882]  ? matrix_alloc_area.constprop.7+0x60/0x90
    [  338.712517]  ? apic_update_irq_cfg+0x82/0xf0
    [  338.717177]  napi_rx_handler+0x14/0xe0 [cxgb4]
    [  338.722015]  net_rx_action+0x2aa/0x3e0
    [  338.726136]  __do_softirq+0xcb/0x280
    [  338.730054]  irq_exit+0xde/0xf0
    [  338.733504]  do_IRQ+0x54/0xd0
    [  338.736745]  common_interrupt+0xf/0xf
    
    Fixes: 104880a6b470 ("crypto: authencesn - Convert to new AEAD...")
    Signed-off-by: Harsh Jain <harsh@chelsio.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3466b8be782a8e55869e782547fc24893c787926
Author: Aymen Sghaier <aymen.sghaier@nxp.com>
Date:   Wed Dec 19 16:36:44 2018 +0200

    crypto: caam - fix zero-length buffer DMA mapping
    
    commit 04e6d25c5bb244c1a37eb9fe0b604cc11a04e8c5 upstream.
    
    Recent changes - probably DMA API related (generic and/or arm64-specific) -
    exposed a case where driver maps a zero-length buffer:
    ahash_init()->ahash_update()->ahash_final() with a zero-length string to
    hash
    
    kernel BUG at kernel/dma/swiotlb.c:475!
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 2 PID: 1823 Comm: cryptomgr_test Not tainted 4.20.0-rc1-00108-g00c9fe37a7f2 #1
    Hardware name: LS1046A RDB Board (DT)
    pstate: 80000005 (Nzcv daif -PAN -UAO)
    pc : swiotlb_tbl_map_single+0x170/0x2b8
    lr : swiotlb_map_page+0x134/0x1f8
    sp : ffff00000f79b8f0
    x29: ffff00000f79b8f0 x28: 0000000000000000
    x27: ffff0000093d0000 x26: 0000000000000000
    x25: 00000000001f3ffe x24: 0000000000200000
    x23: 0000000000000000 x22: 00000009f2c538c0
    x21: ffff800970aeb410 x20: 0000000000000001
    x19: ffff800970aeb410 x18: 0000000000000007
    x17: 000000000000000e x16: 0000000000000001
    x15: 0000000000000019 x14: c32cb8218a167fe8
    x13: ffffffff00000000 x12: ffff80097fdae348
    x11: 0000800976bca000 x10: 0000000000000010
    x9 : 0000000000000000 x8 : ffff0000091fd6c8
    x7 : 0000000000000000 x6 : 00000009f2c538bf
    x5 : 0000000000000000 x4 : 0000000000000001
    x3 : 0000000000000000 x2 : 00000009f2c538c0
    x1 : 00000000f9fff000 x0 : 0000000000000000
    Process cryptomgr_test (pid: 1823, stack limit = 0x(____ptrval____))
    Call trace:
     swiotlb_tbl_map_single+0x170/0x2b8
     swiotlb_map_page+0x134/0x1f8
     ahash_final_no_ctx+0xc4/0x6cc
     ahash_final+0x10/0x18
     crypto_ahash_op+0x30/0x84
     crypto_ahash_final+0x14/0x1c
     __test_hash+0x574/0xe0c
     test_hash+0x28/0x80
     __alg_test_hash+0x84/0xd0
     alg_test_hash+0x78/0x144
     alg_test.part.30+0x12c/0x2b4
     alg_test+0x3c/0x68
     cryptomgr_test+0x44/0x4c
     kthread+0xfc/0x128
     ret_from_fork+0x10/0x18
    Code: d34bfc18 2a1a03f7 1a9f8694 35fff89a (d4210000)
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Aymen Sghaier <aymen.sghaier@nxp.com>
    Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75664d8037efe48e968bda85e690341d12135374
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Jan 7 16:47:33 2019 -0500

    ip: on queued skb use skb_header_pointer instead of pskb_may_pull
    
    [ Upstream commit 4a06fa67c4da20148803525151845276cdb995c1 ]
    
    Commit 2efd4fca703a ("ip: in cmsg IP(V6)_ORIGDSTADDR call
    pskb_may_pull") avoided a read beyond the end of the skb linear
    segment by calling pskb_may_pull.
    
    That function can trigger a BUG_ON in pskb_expand_head if the skb is
    shared, which it is when when peeking. It can also return ENOMEM.
    
    Avoid both by switching to safer skb_header_pointer.
    
    Fixes: 2efd4fca703a ("ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bab999063b9bb3f6c9addc52f54c7688f2a51b6
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Jan 8 12:32:42 2019 -0500

    bonding: update nest level on unlink
    
    [ Upstream commit 001e465f09a18857443489a57e74314a3368c805 ]
    
    A network device stack with multiple layers of bonding devices can
    trigger a false positive lockdep warning. Adding lockdep nest levels
    fixes this. Update the level on both enslave and unlink, to avoid the
    following series of events ..
    
        ip netns add test
        ip netns exec test bash
        ip link set dev lo addr 00:11:22:33:44:55
        ip link set dev lo down
    
        ip link add dev bond1 type bond
        ip link add dev bond2 type bond
    
        ip link set dev lo master bond1
        ip link set dev bond1 master bond2
    
        ip link set dev bond1 nomaster
        ip link set dev bond2 master bond1
    
    .. from still generating a splat:
    
        [  193.652127] ======================================================
        [  193.658231] WARNING: possible circular locking dependency detected
        [  193.664350] 4.20.0 #8 Not tainted
        [  193.668310] ------------------------------------------------------
        [  193.674417] ip/15577 is trying to acquire lock:
        [  193.678897] 00000000a40e3b69 (&(&bond->stats_lock)->rlock#3/3){+.+.}, at: bond_get_stats+0x58/0x290
        [  193.687851]
                   but task is already holding lock:
        [  193.693625] 00000000807b9d9f (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0x58/0x290
    
        [..]
    
        [  193.851092]        lock_acquire+0xa7/0x190
        [  193.855138]        _raw_spin_lock_nested+0x2d/0x40
        [  193.859878]        bond_get_stats+0x58/0x290
        [  193.864093]        dev_get_stats+0x5a/0xc0
        [  193.868140]        bond_get_stats+0x105/0x290
        [  193.872444]        dev_get_stats+0x5a/0xc0
        [  193.876493]        rtnl_fill_stats+0x40/0x130
        [  193.880797]        rtnl_fill_ifinfo+0x6c5/0xdc0
        [  193.885271]        rtmsg_ifinfo_build_skb+0x86/0xe0
        [  193.890091]        rtnetlink_event+0x5b/0xa0
        [  193.894320]        raw_notifier_call_chain+0x43/0x60
        [  193.899225]        netdev_change_features+0x50/0xa0
        [  193.904044]        bond_compute_features.isra.46+0x1ab/0x270
        [  193.909640]        bond_enslave+0x141d/0x15b0
        [  193.913946]        do_set_master+0x89/0xa0
        [  193.918016]        do_setlink+0x37c/0xda0
        [  193.921980]        __rtnl_newlink+0x499/0x890
        [  193.926281]        rtnl_newlink+0x48/0x70
        [  193.930238]        rtnetlink_rcv_msg+0x171/0x4b0
        [  193.934801]        netlink_rcv_skb+0xd1/0x110
        [  193.939103]        rtnetlink_rcv+0x15/0x20
        [  193.943151]        netlink_unicast+0x3b5/0x520
        [  193.947544]        netlink_sendmsg+0x2fd/0x3f0
        [  193.951942]        sock_sendmsg+0x38/0x50
        [  193.955899]        ___sys_sendmsg+0x2ba/0x2d0
        [  193.960205]        __x64_sys_sendmsg+0xad/0x100
        [  193.964687]        do_syscall_64+0x5a/0x460
        [  193.968823]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fixes: 7e2556e40026 ("bonding: avoid lockdep confusion in bond_get_stats()")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6740236de302817818c319567dea9ecd3cb1454c
Author: Jason Gunthorpe <jgg@mellanox.com>
Date:   Tue Jan 8 23:27:06 2019 +0000

    packet: Do not leak dev refcounts on error exit
    
    [ Upstream commit d972f3dce8d161e2142da0ab1ef25df00e2f21a9 ]
    
    'dev' is non NULL when the addr_len check triggers so it must goto a label
    that does the dev_put otherwise dev will have a leaked refcount.
    
    This bug causes the ib_ipoib module to become unloadable when using
    systemd-network as it triggers this check on InfiniBand links.
    
    Fixes: 99137b7888f4 ("packet: validate address length")
    Reported-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4683849b9c2b803f4dbbffe9619e56d025e8683
Author: JianJhen Chen <kchen@synology.com>
Date:   Sun Jan 6 11:28:13 2019 +0800

    net: bridge: fix a bug on using a neighbour cache entry without checking its state
    
    [ Upstream commit 4c84edc11b76590859b1e45dd676074c59602dc4 ]
    
    When handling DNAT'ed packets on a bridge device, the neighbour cache entry
    from lookup was used without checking its state. It means that a cache entry
    in the NUD_STALE state will be used directly instead of entering the NUD_DELAY
    state to confirm the reachability of the neighbor.
    
    This problem becomes worse after commit 2724680bceee ("neigh: Keep neighbour
    cache entries if number of them is small enough."), since all neighbour cache
    entries in the NUD_STALE state will be kept in the neighbour table as long as
    the number of cache entries does not exceed the value specified in gc_thresh1.
    
    This commit validates the state of a neighbour cache entry before using
    the entry.
    
    Signed-off-by: JianJhen Chen <kchen@synology.com>
    Reviewed-by: JinLin Chen <jlchen@synology.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c809028e773de4f4c5c40af3caad9e3e936ecfb9
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 8 04:06:14 2019 -0800

    ipv6: fix kernel-infoleak in ipv6_local_error()
    
    [ Upstream commit 7d033c9f6a7fd3821af75620a0257db87c2b552a ]
    
    This patch makes sure the flow label in the IPv6 header
    forged in ipv6_local_error() is initialized.
    
    BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
    CPU: 1 PID: 24675 Comm: syz-executor1 Not tainted 4.20.0-rc7+ #4
    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+0x173/0x1d0 lib/dump_stack.c:113
     kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
     kmsan_internal_check_memory+0x455/0xb00 mm/kmsan/kmsan.c:675
     kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
     _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
     copy_to_user include/linux/uaccess.h:177 [inline]
     move_addr_to_user+0x2e9/0x4f0 net/socket.c:227
     ___sys_recvmsg+0x5d7/0x1140 net/socket.c:2284
     __sys_recvmsg net/socket.c:2327 [inline]
     __do_sys_recvmsg net/socket.c:2337 [inline]
     __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
     __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    RIP: 0033:0x457ec9
    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:00007f8750c06c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457ec9
    RDX: 0000000000002000 RSI: 0000000020000400 RDI: 0000000000000005
    RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8750c076d4
    R13: 00000000004c4a60 R14: 00000000004d8140 R15: 00000000ffffffff
    
    Uninit was stored to memory at:
     kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
     kmsan_save_stack mm/kmsan/kmsan.c:219 [inline]
     kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:439
     __msan_chain_origin+0x70/0xe0 mm/kmsan/kmsan_instr.c:200
     ipv6_recv_error+0x1e3f/0x1eb0 net/ipv6/datagram.c:475
     udpv6_recvmsg+0x398/0x2ab0 net/ipv6/udp.c:335
     inet_recvmsg+0x4fb/0x600 net/ipv4/af_inet.c:830
     sock_recvmsg_nosec net/socket.c:794 [inline]
     sock_recvmsg+0x1d1/0x230 net/socket.c:801
     ___sys_recvmsg+0x4d5/0x1140 net/socket.c:2278
     __sys_recvmsg net/socket.c:2327 [inline]
     __do_sys_recvmsg net/socket.c:2337 [inline]
     __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
     __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    
    Uninit was created at:
     kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
     kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158
     kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176
     kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185
     slab_post_alloc_hook mm/slab.h:446 [inline]
     slab_alloc_node mm/slub.c:2759 [inline]
     __kmalloc_node_track_caller+0xe18/0x1030 mm/slub.c:4383
     __kmalloc_reserve net/core/skbuff.c:137 [inline]
     __alloc_skb+0x309/0xa20 net/core/skbuff.c:205
     alloc_skb include/linux/skbuff.h:998 [inline]
     ipv6_local_error+0x1a7/0x9e0 net/ipv6/datagram.c:334
     __ip6_append_data+0x129f/0x4fd0 net/ipv6/ip6_output.c:1311
     ip6_make_skb+0x6cc/0xcf0 net/ipv6/ip6_output.c:1775
     udpv6_sendmsg+0x3f8e/0x45d0 net/ipv6/udp.c:1384
     inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
     sock_sendmsg_nosec net/socket.c:621 [inline]
     sock_sendmsg net/socket.c:631 [inline]
     __sys_sendto+0x8c4/0xac0 net/socket.c:1788
     __do_sys_sendto net/socket.c:1800 [inline]
     __se_sys_sendto+0x107/0x130 net/socket.c:1796
     __x64_sys_sendto+0x6e/0x90 net/socket.c:1796
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    
    Bytes 4-7 of 28 are uninitialized
    Memory access of size 28 starts at ffff8881937bfce0
    Data copied to user address 0000000020000000
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    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 fea3f83ee00525e604dccd2673a33cefd25bc76d
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Jan 18 17:56:33 2019 +0000

    arm64: Don't trap host pointer auth use to EL2
    
    [ Backport of upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ]
    
    To allow EL0 (and/or EL1) to use pointer authentication functionality,
    we must ensure that pointer authentication instructions and accesses to
    pointer authentication keys are not trapped to EL2.
    
    This patch ensures that HCR_EL2 is configured appropriately when the
    kernel is booted at EL2. For non-VHE kernels we set HCR_EL2.{API,APK},
    ensuring that EL1 can access keys and permit EL0 use of instructions.
    For VHE kernels host EL0 (TGE && E2H) is unaffected by these settings,
    and it doesn't matter how we configure HCR_EL2.{API,APK}, so we don't
    bother setting them.
    
    This does not enable support for KVM guests, since KVM manages HCR_EL2
    itself when running VMs.
    
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Christoffer Dall <christoffer.dall@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: kvmarm@lists.cs.columbia.edu
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    [kristina: backport to 4.14.y: adjust context]
    Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ef8d21b719391d2fd831a1fabbb33cc75bef0c1
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Jan 18 17:56:32 2019 +0000

    arm64/kvm: consistently handle host HCR_EL2 flags
    
    [ Backport of upstream commit 4eaed6aa2c628101246bcabc91b203bfac1193f8 ]
    
    In KVM we define the configuration of HCR_EL2 for a VHE HOST in
    HCR_HOST_VHE_FLAGS, but we don't have a similar definition for the
    non-VHE host flags, and open-code HCR_RW. Further, in head.S we
    open-code the flags for VHE and non-VHE configurations.
    
    In future, we're going to want to configure more flags for the host, so
    lets add a HCR_HOST_NVHE_FLAGS defintion, and consistently use both
    HCR_HOST_VHE_FLAGS and HCR_HOST_NVHE_FLAGS in the kvm code and head.S.
    
    We now use mov_q to generate the HCR_EL2 value, as we use when
    configuring other registers in head.S.
    
    Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: kvmarm@lists.cs.columbia.edu
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    [kristina: backport to 4.14.y: adjust context]
    Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccc67efce720211d0a3dceaf1ec7949777a1836a
Author: Varun Prakash <varun@chelsio.com>
Date:   Fri Nov 9 20:59:01 2018 +0530

    scsi: target: iscsi: cxgbit: fix csk leak
    
    [ Upstream commit ed076c55b359cc9982ca8b065bcc01675f7365f6 ]
    
    In case of arp failure call cxgbit_put_csk() to free csk.
    
    Signed-off-by: Varun Prakash <varun@chelsio.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c62825e9765e01cc73171256588d9ca67216029
Author: Sasha Levin <sashal@kernel.org>
Date:   Mon Jan 14 10:01:30 2019 -0500

    Revert "scsi: target: iscsi: cxgbit: fix csk leak"
    
    This reverts commit b831528038e3cad0d745c53bcaeedb642f5cbc1f.
    
    A wrong commit message was used for the stable commit because of a human
    error (and duplicate commit subject lines).
    
    This patch reverts this error, and the following patches add the two
    upstream commits.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d93cef31a56bcf111a92977f70df8d6a9f0bde47
Author: Xunlei Pang <xlpang@linux.alibaba.com>
Date:   Wed Jun 20 18:18:33 2018 +0800

    sched/fair: Fix bandwidth timer clock drift condition
    
    commit 512ac999d2755d2b7109e996a76b6fb8b888631d upstream.
    
    I noticed that cgroup task groups constantly get throttled even
    if they have low CPU usage, this causes some jitters on the response
    time to some of our business containers when enabling CPU quotas.
    
    It's very simple to reproduce:
    
      mkdir /sys/fs/cgroup/cpu/test
      cd /sys/fs/cgroup/cpu/test
      echo 100000 > cpu.cfs_quota_us
      echo $$ > tasks
    
    then repeat:
    
      cat cpu.stat | grep nr_throttled  # nr_throttled will increase steadily
    
    After some analysis, we found that cfs_rq::runtime_remaining will
    be cleared by expire_cfs_rq_runtime() due to two equal but stale
    "cfs_{b|q}->runtime_expires" after period timer is re-armed.
    
    The current condition to judge clock drift in expire_cfs_rq_runtime()
    is wrong, the two runtime_expires are actually the same when clock
    drift happens, so this condtion can never hit. The orginal design was
    correctly done by this commit:
    
      a9cf55b28610 ("sched: Expire invalid runtime")
    
    ... but was changed to be the current implementation due to its locking bug.
    
    This patch introduces another way, it adds a new field in both structures
    cfs_rq and cfs_bandwidth to record the expiration update sequence, and
    uses them to figure out if clock drift happens (true if they are equal).
    
    Signed-off-by: Xunlei Pang <xlpang@linux.alibaba.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    [alakeshh: backport: Fixed merge conflicts:
     - sched.h: Fix the indentation and order in which the variables are
       declared to match with coding style of the existing code in 4.14
       Struct members of same type were declared in separate lines in
       upstream patch which has been changed back to having multiple
       members of same type in the same line.
       e.g. int a; int b; ->  int a, b; ]
    Signed-off-by: Alakesh Haloi <alakeshh@amazon.com>
    Reviewed-by: Ben Segall <bsegall@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org> # 4.14.x
    Fixes: 51f2176d74ac ("sched/fair: Fix unlocked reads of some cfs_b->quota/period")
    Link: http://lkml.kernel.org/r/20180620101834.24455-1-xlpang@linux.alibaba.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e643473c99ef5224315f0825fb00326fb984693
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Jan 17 00:25:58 2019 +0000

    media: em28xx: Fix misplaced reset of dev->v4l::field_count
    
    The backport of commit afeaade90db4 "media: em28xx: make
    v4l2-compliance happier by starting sequence on zero" added a
    reset on em28xx_v4l2::field_count to em28xx_enable_analog_tuner()
    but it should be done in em28xx_start_analog_streaming().
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4abb6960f61ca52ff5a61c97bde10e9e7edf548e
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Tue Dec 4 13:25:32 2018 +0100

    mmc: sdhci-msm: Disable CDR function on TX
    
    commit a89e7bcb18081c611eb6cf50edd440fa4983a71a upstream.
    
    The Clock Data Recovery (CDR) circuit allows to automatically adjust
    the RX sampling-point/phase for high frequency cards (SDR104, HS200...).
    CDR is automatically enabled during DLL configuration.
    However, according to the APQ8016 reference manual, this function
    must be disabled during TX and tuning phase in order to prevent any
    interferences during tuning challenges and unexpected phase alteration
    during TX transfers.
    
    This patch enables/disables CDR according to the current transfer mode.
    
    This fixes sporadic write transfer issues observed with some SDR104 and
    HS200 cards.
    
    Inspired by sdhci-msm downstream patch:
    https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/432516/
    
    Reported-by: Leonid Segal <leonid.s@variscite.com>
    Reported-by: Manabu Igusa <migusa@arrowjapan.com>
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Acked-by: Georgi Djakov <georgi.djakov@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    [georgi: backport to v4.14]
    Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39ff087b5c6be2ff0b08e617d334e5bf72a08b44
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Fri Jan 4 15:55:26 2019 +0100

    can: gw: ensure DLC boundaries after CAN frame modification
    
    commit 0aaa81377c5a01f686bcdb8c7a6929a7bf330c68 upstream.
    
    Muyu Yu provided a POC where user root with CAP_NET_ADMIN can create a CAN
    frame modification rule that makes the data length code a higher value than
    the available CAN frame data size. In combination with a configured checksum
    calculation where the result is stored relatively to the end of the data
    (e.g. cgw_csum_xor_rel) the tail of the skb (e.g. frag_list pointer in
    skb_shared_info) can be rewritten which finally can cause a system crash.
    
    Michael Kubecek suggested to drop frames that have a DLC exceeding the
    available space after the modification process and provided a patch that can
    handle CAN FD frames too. Within this patch we also limit the length for the
    checksum calculations to the maximum of Classic CAN data length (8).
    
    CAN frames that are dropped by these additional checks are counted with the
    CGW_DELETED counter which indicates misconfigurations in can-gw rules.
    
    This fixes CVE-2019-3701.
    
    Reported-by: Muyu Yu <ieatmuttonchuan@gmail.com>
    Reported-by: Marcus Meissner <meissner@suse.de>
    Suggested-by: Michal Kubecek <mkubecek@suse.cz>
    Tested-by: Muyu Yu <ieatmuttonchuan@gmail.com>
    Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Cc: linux-stable <stable@vger.kernel.org> # >= v3.2
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb7f9a466349842d39c2ccb27bd939baf333b6a4
Author: Dmitry Safonov <dima@arista.com>
Date:   Wed Jan 9 01:17:40 2019 +0000

    tty: Don't hold ldisc lock in tty_reopen() if ldisc present
    
    commit d3736d82e8169768218ee0ef68718875918091a0 upstream.
    
    Try to get reference for ldisc during tty_reopen().
    If ldisc present, we don't need to do tty_ldisc_reinit() and lock the
    write side for line discipline semaphore.
    Effectively, it optimizes fast-path for tty_reopen(), but more
    importantly it won't interrupt ongoing IO on the tty as no ldisc change
    is needed.
    Fixes user-visible issue when tty_reopen() interrupted login process for
    user with a long password, observed and reported by Lukas.
    
    Fixes: c96cf923a98d ("tty: Don't block on IO when ldisc change is pending")
    Fixes: 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()")
    Cc: Jiri Slaby <jslaby@suse.com>
    Reported-by: Lukas F. Hartmann <lukas@mntmn.com>
    Tested-by: Lukas F. Hartmann <lukas@mntmn.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4086e2872f72fcc3539dcae9b6daebe29161dfc4
Author: Dmitry Safonov <dima@arista.com>
Date:   Thu Nov 1 00:24:49 2018 +0000

    tty: Simplify tty->count math in tty_reopen()
    
    commit cf62a1a13749db0d32b5cdd800ea91a4087319de upstream.
    
    As notted by Jiri, tty_ldisc_reinit() shouldn't rely on tty counter.
    Simplify math by increasing the counter after reinit success.
    
    Cc: Jiri Slaby <jslaby@suse.com>
    Link: lkml.kernel.org/r/<20180829022353.23568-2-dima@arista.com>
    Suggested-by: Jiri Slaby <jslaby@suse.com>
    Reviewed-by: Jiri Slaby <jslaby@suse.cz>
    Tested-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 108bf6a21ee3ea982af8682517afb63f536edcc2
Author: Dmitry Safonov <dima@arista.com>
Date:   Thu Nov 1 00:24:47 2018 +0000

    tty: Hold tty_ldisc_lock() during tty_reopen()
    
    commit 83d817f41070c48bc3eb7ec18e43000a548fca5c upstream.
    
    tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup()
    nor set_ldisc() nor tty_ldisc_release() as they use tty lock.
    But it races with anyone who expects line discipline to be the same
    after hoding read semaphore in tty_ldisc_ref().
    
    We've seen the following crash on v4.9.108 stable:
    
    BUG: unable to handle kernel paging request at 0000000000002260
    IP: [..] n_tty_receive_buf_common+0x5f/0x86d
    Workqueue: events_unbound flush_to_ldisc
    Call Trace:
     [..] n_tty_receive_buf2
     [..] tty_ldisc_receive_buf
     [..] flush_to_ldisc
     [..] process_one_work
     [..] worker_thread
     [..] kthread
     [..] ret_from_fork
    
    tty_ldisc_reinit() should be called with ldisc_sem hold for writing,
    which will protect any reader against line discipline changes.
    
    Cc: Jiri Slaby <jslaby@suse.com>
    Cc: stable@vger.kernel.org # b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf")
    Reviewed-by: Jiri Slaby <jslaby@suse.cz>
    Reported-by: syzbot+3aa9784721dfb90e984d@syzkaller.appspotmail.com
    Tested-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Tested-by: Tycho Andersen <tycho@tycho.ws>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe13700236298671d23dc864eda6a3166092f502
Author: Dmitry Safonov <dima@arista.com>
Date:   Thu Nov 1 00:24:46 2018 +0000

    tty/ldsem: Wake up readers after timed out down_write()
    
    commit 231f8fd0cca078bd4396dd7e380db813ac5736e2 upstream.
    
    ldsem_down_read() will sleep if there is pending writer in the queue.
    If the writer times out, readers in the queue should be woken up,
    otherwise they may miss a chance to acquire the semaphore until the last
    active reader will do ldsem_up_read().
    
    There was a couple of reports where there was one active reader and
    other readers soft locked up:
      Showing all locks held in the system:
      2 locks held by khungtaskd/17:
       #0:  (rcu_read_lock){......}, at: watchdog+0x124/0x6d1
       #1:  (tasklist_lock){.+.+..}, at: debug_show_all_locks+0x72/0x2d3
      2 locks held by askfirst/123:
       #0:  (&tty->ldisc_sem){.+.+.+}, at: ldsem_down_read+0x46/0x58
       #1:  (&ldata->atomic_read_lock){+.+...}, at: n_tty_read+0x115/0xbe4
    
    Prevent readers wait for active readers to release ldisc semaphore.
    
    Link: lkml.kernel.org/r/20171121132855.ajdv4k6swzhvktl6@wfg-t540p.sh.intel.com
    Link: lkml.kernel.org/r/20180907045041.GF1110@shao2-debian
    Cc: Jiri Slaby <jslaby@suse.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Reported-by: kernel test robot <rong.a.chen@intel.com>
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>