1. 26 1月, 2019 14 次提交
  2. 23 1月, 2019 26 次提交
    • G
      Linux 4.19.17 · 23b6b8bf
      Greg Kroah-Hartman 提交于
      23b6b8bf
    • J
      nbd: Use set_blocksize() to set device blocksize · 9a9c3c02
      Jan Kara 提交于
      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: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9a9c3c02
    • M
      media: vb2: be sure to unlock mutex on errors · 685cc9c3
      Mauro Carvalho Chehab 提交于
      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: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      685cc9c3
    • S
      selftests: Fix test errors related to lib.mk khdr target · 7696248f
      Shuah Khan 提交于
      commit 211929fd3f7c8de4d541b1cc243b82830e5ea1e8 upstream.
      
      Commit b2d35fa5 ("selftests: add headers_install to lib.mk") added
      khdr target to run headers_install target from the main Makefile. The
      logic uses KSFT_KHDR_INSTALL and top_srcdir as controls to initialize
      variables and include files to run headers_install from the top level
      Makefile. There are a few problems with this logic.
      
      1. Exposes top_srcdir to all tests
      2. Common logic impacts all tests
      3. Uses KSFT_KHDR_INSTALL, top_srcdir, and khdr in an adhoc way. Tests
         add "khdr" dependency in their Makefiles to TEST_PROGS_EXTENDED in
         some cases, and STATIC_LIBS in other cases. This makes this framework
         confusing to use.
      
      The common logic that runs for all tests even when KSFT_KHDR_INSTALL
      isn't defined by the test. top_srcdir is initialized to a default value
      when test doesn't initialize it. It works for all tests without a sub-dir
      structure and tests with sub-dir structure fail to build.
      
      e.g: make -C sparc64/drivers/ or make -C drivers/dma-buf
      
      ../../lib.mk:20: ../../../../scripts/subarch.include: No such file or directory
      make: *** No rule to make target '../../../../scripts/subarch.include'.  Stop.
      
      There is no reason to require all tests to define top_srcdir and there is
      no need to require tests to add khdr dependency using adhoc changes to
      TEST_* and other variables.
      
      Fix it with a consistent use of KSFT_KHDR_INSTALL and top_srcdir from tests
      that have the dependency on headers_install.
      
      Change common logic to include khdr target define and "all" target with
      dependency on khdr when KSFT_KHDR_INSTALL is defined.
      
      Only tests that have dependency on headers_install have to define just
      the KSFT_KHDR_INSTALL, and top_srcdir variables and there is no need to
      specify khdr dependency in the test Makefiles.
      
      Fixes: b2d35fa5 ("selftests: add headers_install to lib.mk")
      Cc: stable@vger.kernel.org
      Signed-off-by: NShuah Khan <shuah@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      7696248f
    • I
      drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock · 241e5148
      Ivan Mironov 提交于
      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: NIvan Mironov <mironov.ivan@gmail.com>
      Cc: stable@vger.kernel.org
      Fixes: 79e53945 ("DRM: i915: add mode setting support")
      Fixes: 771fe6b9 ("drm/radeon: introduce kernel modesetting for radeon hardware")
      Fixes: 785b93ef ("drm/kms: move driver specific fb common code to helper functions (v2)")
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-3-mironov.ivan@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      241e5148
    • J
      loop: drop caches if offset or block_size are changed · 8868a72d
      Jaegeuk Kim 提交于
      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: NMartijn Coenen <maco@google.com>
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8868a72d
    • T
      loop: Fix double mutex_unlock(&loop_ctl_mutex) in loop_control_ioctl() · 30805ece
      Tetsuo Handa 提交于
      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: Nsyzbot <syzbot+c0138741c2290fc5e63f@syzkaller.appspotmail.com>
      Reviewed-by: NMing Lei <ming.lei@redhat.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30805ece
    • J
      loop: Get rid of 'nested' acquisition of loop_ctl_mutex · b42e24aa
      Jan Kara 提交于
      commit c28445fa06a3a54e06938559b9514c5a7f01c90f upstream.
      
      The nested acquisition of loop_ctl_mutex (->lo_ctl_mutex back then) has
      been introduced by commit f028f3b2 "loop: fix circular locking in
      loop_clr_fd()" to fix lockdep complains about bd_mutex being acquired
      after lo_ctl_mutex during partition rereading. Now that these are
      properly fixed, let's stop fooling lockdep.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b42e24aa
    • J
      loop: Avoid circular locking dependency between loop_ctl_mutex and bd_mutex · 5c684c25
      Jan Kara 提交于
      commit 1dded9acf6dc9a34cd27fcf8815507e4e65b3c4f upstream.
      
      Code in loop_change_fd() drops reference to the old file (and also the
      new file in a failure case) under loop_ctl_mutex. Similarly to a
      situation in loop_set_fd() this can create a circular locking dependency
      if this was the last reference holding the file open. Delay dropping of
      the file reference until we have released loop_ctl_mutex.
      Reported-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c684c25
    • J
      loop: Fix deadlock when calling blkdev_reread_part() · 5f0db37d
      Jan Kara 提交于
      commit 0da03cab87e6323ff2e05b14bc7d5c6fcc531efd upstream.
      
      Calling blkdev_reread_part() under loop_ctl_mutex causes lockdep to
      complain about circular lock dependency between bdev->bd_mutex and
      lo->lo_ctl_mutex. The problem is that on loop device open or close
      lo_open() and lo_release() get called with bdev->bd_mutex held and they
      need to acquire loop_ctl_mutex. OTOH when loop_reread_partitions() is
      called with loop_ctl_mutex held, it will call blkdev_reread_part() which
      acquires bdev->bd_mutex. See syzbot report for details [1].
      
      Move call to blkdev_reread_part() in __loop_clr_fd() from under
      loop_ctl_mutex to finish fixing of the lockdep warning and the possible
      deadlock.
      
      [1] https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d1588Reported-by: Nsyzbot <syzbot+4684a000d5abdade83fac55b1e7d1f935ef1936e@syzkaller.appspotmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f0db37d
    • J
      loop: Move loop_reread_partitions() out of loop_ctl_mutex · 6e0d6935
      Jan Kara 提交于
      commit 85b0a54a82e4fbceeb1aebb7cb6909edd1a24668 upstream.
      
      Calling loop_reread_partitions() under loop_ctl_mutex causes lockdep to
      complain about circular lock dependency between bdev->bd_mutex and
      lo->lo_ctl_mutex. The problem is that on loop device open or close
      lo_open() and lo_release() get called with bdev->bd_mutex held and they
      need to acquire loop_ctl_mutex. OTOH when loop_reread_partitions() is
      called with loop_ctl_mutex held, it will call blkdev_reread_part() which
      acquires bdev->bd_mutex. See syzbot report for details [1].
      
      Move all calls of loop_rescan_partitions() out of loop_ctl_mutex to
      avoid lockdep warning and fix deadlock possibility.
      
      [1] https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d1588Reported-by: Nsyzbot <syzbot+4684a000d5abdade83fac55b1e7d1f935ef1936e@syzkaller.appspotmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e0d6935
    • J
      loop: Move special partition reread handling in loop_clr_fd() · ed281a72
      Jan Kara 提交于
      commit d57f3374ba4817f7c8d26fae8a13d20ac8d31b92 upstream.
      
      The call of __blkdev_reread_part() from loop_reread_partition() happens
      only when we need to invalidate partitions from loop_release(). Thus
      move a detection for this into loop_clr_fd() and simplify
      loop_reread_partition().
      
      This makes loop_reread_partition() safe to use without loop_ctl_mutex
      because we use only lo->lo_number and lo->lo_file_name in case of error
      for reporting purposes (thus possibly reporting outdate information is
      not a big deal) and we are safe from 'lo' going away under us by
      elevated lo->lo_refcnt.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed281a72
    • J
      loop: Push loop_ctl_mutex down to loop_change_fd() · dc717408
      Jan Kara 提交于
      commit c371077000f4138ee3c15fbed50101ff24bdc91d upstream.
      
      Push loop_ctl_mutex down to loop_change_fd(). We will need this to be
      able to call loop_reread_partitions() without loop_ctl_mutex.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc717408
    • J
      loop: Push loop_ctl_mutex down to loop_set_fd() · 9218b108
      Jan Kara 提交于
      commit 757ecf40b7e029529768eb5f9562d5eeb3002106 upstream.
      
      Push lo_ctl_mutex down to loop_set_fd(). We will need this to be able to
      call loop_reread_partitions() without lo_ctl_mutex.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9218b108
    • J
      loop: Push loop_ctl_mutex down to loop_set_status() · 90386ad7
      Jan Kara 提交于
      commit 550df5fdacff94229cde0ed9b8085155654c1696 upstream.
      
      Push loop_ctl_mutex down to loop_set_status(). We will need this to be
      able to call loop_reread_partitions() without loop_ctl_mutex.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90386ad7
    • J
      loop: Push loop_ctl_mutex down to loop_get_status() · 8de64127
      Jan Kara 提交于
      commit 4a5ce9ba5877e4640200d84a735361306ad1a1b8 upstream.
      
      Push loop_ctl_mutex down to loop_get_status() to avoid the unusual
      convention that the function gets called with loop_ctl_mutex held and
      releases it.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8de64127
    • J
      loop: Push loop_ctl_mutex down into loop_clr_fd() · ed87dc66
      Jan Kara 提交于
      commit 7ccd0791d98531df7cd59e92d55e4f063d48a070 upstream.
      
      loop_clr_fd() has a weird locking convention that is expects
      loop_ctl_mutex held, releases it on success and keeps it on failure.
      Untangle the mess by moving locking of loop_ctl_mutex into
      loop_clr_fd().
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed87dc66
    • J
      loop: Split setting of lo_state from loop_clr_fd · 18974320
      Jan Kara 提交于
      commit a2505b799a496b7b84d9a4a14ec870ff9e42e11b upstream.
      
      Move setting of lo_state to Lo_rundown out into the callers. That will
      allow us to unlock loop_ctl_mutex while the loop device is protected
      from other changes by its special state.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18974320
    • J
      loop: Push lo_ctl_mutex down into individual ioctls · b8463897
      Jan Kara 提交于
      commit a13165441d58b216adbd50252a9cc829d78a6bce upstream.
      
      Push acquisition of lo_ctl_mutex down into individual ioctl handling
      branches. This is a preparatory step for pushing the lock down into
      individual ioctl handling functions so that they can release the lock as
      they need it. We also factor out some simple ioctl handlers that will
      not need any special handling to reduce unnecessary code duplication.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8463897
    • J
      loop: Get rid of loop_index_mutex · ea5df507
      Jan Kara 提交于
      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: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea5df507
    • J
      loop: Fold __loop_release into loop_release · 38d9cce3
      Jan Kara 提交于
      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: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38d9cce3
    • T
      block/loop: Use global lock for ioctl() operation. · 342b3360
      Tetsuo Handa 提交于
      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=bf154052f0eea4bc7712499e4569505907d15889Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: Nsyzbot <syzbot+bf89c128e05dd6c62523@syzkaller.appspotmail.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      342b3360
    • T
      block/loop: Don't grab "struct file" for vfs_getattr() operation. · f5d3c785
      Tetsuo Handa 提交于
      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: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5d3c785
    • Y
      tipc: fix uninit-value in tipc_nl_compat_doit · 21172412
      Ying Xue 提交于
      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: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21172412
    • Y
      tipc: fix uninit-value in tipc_nl_compat_name_table_dump · 2d5fc1d4
      Ying Xue 提交于
      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: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d5fc1d4
    • Y
      tipc: fix uninit-value in tipc_nl_compat_link_set · 04d87429
      Ying Xue 提交于
      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: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04d87429