1. 29 9月, 2017 3 次提交
  2. 28 9月, 2017 1 次提交
    • A
      tun: bail out from tun_get_user() if the skb is empty · 2580c4c1
      Alexander Potapenko 提交于
      KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
      skb->data[0] in the case the skb is empty (i.e. skb->len is 0):
      
      ================================================
      BUG: KMSAN: use of uninitialized memory in tun_get_user+0x19ba/0x3770
      CPU: 0 PID: 3051 Comm: probe Not tainted 4.13.0+ #3140
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
      ...
       __msan_warning_32+0x66/0xb0 mm/kmsan/kmsan_instr.c:477
       tun_get_user+0x19ba/0x3770 drivers/net/tun.c:1301
       tun_chr_write_iter+0x19f/0x300 drivers/net/tun.c:1365
       call_write_iter ./include/linux/fs.h:1743
       new_sync_write fs/read_write.c:457
       __vfs_write+0x6c3/0x7f0 fs/read_write.c:470
       vfs_write+0x3e4/0x770 fs/read_write.c:518
       SYSC_write+0x12f/0x2b0 fs/read_write.c:565
       SyS_write+0x55/0x80 fs/read_write.c:557
       do_syscall_64+0x242/0x330 arch/x86/entry/common.c:284
       entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:245
      ...
      origin:
      ...
       kmsan_poison_shadow+0x6e/0xc0 mm/kmsan/kmsan.c:211
       slab_alloc_node mm/slub.c:2732
       __kmalloc_node_track_caller+0x351/0x370 mm/slub.c:4351
       __kmalloc_reserve net/core/skbuff.c:138
       __alloc_skb+0x26a/0x810 net/core/skbuff.c:231
       alloc_skb ./include/linux/skbuff.h:903
       alloc_skb_with_frags+0x1d7/0xc80 net/core/skbuff.c:4756
       sock_alloc_send_pskb+0xabf/0xfe0 net/core/sock.c:2037
       tun_alloc_skb drivers/net/tun.c:1144
       tun_get_user+0x9a8/0x3770 drivers/net/tun.c:1274
       tun_chr_write_iter+0x19f/0x300 drivers/net/tun.c:1365
       call_write_iter ./include/linux/fs.h:1743
       new_sync_write fs/read_write.c:457
       __vfs_write+0x6c3/0x7f0 fs/read_write.c:470
       vfs_write+0x3e4/0x770 fs/read_write.c:518
       SYSC_write+0x12f/0x2b0 fs/read_write.c:565
       SyS_write+0x55/0x80 fs/read_write.c:557
       do_syscall_64+0x242/0x330 arch/x86/entry/common.c:284
       return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:245
      ================================================
      
      Make sure tun_get_user() doesn't touch skb->data[0] unless there is
      actual data.
      
      C reproducer below:
      ==========================
          // autogenerated by syzkaller (http://github.com/google/syzkaller)
      
          #define _GNU_SOURCE
      
          #include <fcntl.h>
          #include <linux/if_tun.h>
          #include <netinet/ip.h>
          #include <net/if.h>
          #include <string.h>
          #include <sys/ioctl.h>
      
          int main()
          {
            int sock = socket(PF_INET, SOCK_STREAM, IPPROTO_IP);
            int tun_fd = open("/dev/net/tun", O_RDWR);
            struct ifreq req;
            memset(&req, 0, sizeof(struct ifreq));
            strcpy((char*)&req.ifr_name, "gre0");
            req.ifr_flags = IFF_UP | IFF_MULTICAST;
            ioctl(tun_fd, TUNSETIFF, &req);
            ioctl(sock, SIOCSIFFLAGS, "gre0");
            write(tun_fd, "hi", 0);
            return 0;
          }
      ==========================
      Signed-off-by: NAlexander Potapenko <glider@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2580c4c1
  3. 27 9月, 2017 4 次提交
  4. 26 9月, 2017 2 次提交
  5. 24 9月, 2017 2 次提交
    • S
      net: qualcomm: rmnet: Fix rcu splat in rmnet_is_real_dev_registered · 5c346525
      Subash Abhinov Kasiviswanathan 提交于
      Xiaolong reported a suspicious rcu_dereference_check in the device
      unregister notifier callback. Since we do not dereference the
      rx_handler_data, it's ok to just check for the value of the pointer.
      Note that this section is already protected by rtnl_lock.
      
      [  101.364846] WARNING: suspicious RCU usage
      [  101.365654] 4.13.0-rc6-01701-gceed73a2 #1 Not tainted
      [  101.370873] -----------------------------
      [  101.372472] drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c:57 suspicious rcu_dereference_check() usage!
      [  101.374427]
      [  101.374427] other info that might help us debug this:
      [  101.374427]
      [  101.387491]
      [  101.387491] rcu_scheduler_active = 2, debug_locks = 1
      [  101.389368] 1 lock held by trinity-main/2809:
      [  101.390736]  #0:  (rtnl_mutex){+.+.+.}, at: [<8146085b>] rtnl_lock+0xf/0x11
      [  101.395482]
      [  101.395482] stack backtrace:
      [  101.396948] CPU: 0 PID: 2809 Comm: trinity-main Not tainted 4.13.0-rc6-01701-gceed73a2 #1
      [  101.398857] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
      [  101.401079] Call Trace:
      [  101.401656]  dump_stack+0xa1/0xeb
      [  101.402871]  lockdep_rcu_suspicious+0xc7/0xd0
      [  101.403665]  rmnet_is_real_dev_registered+0x40/0x4e
      [  101.405199]  rmnet_config_notify_cb+0x2c/0x142
      [  101.406344]  ? wireless_nlevent_flush+0x47/0x71
      [  101.407385]  notifier_call_chain+0x2d/0x47
      [  101.408645]  raw_notifier_call_chain+0xc/0xe
      [  101.409882]  call_netdevice_notifiers_info+0x41/0x49
      [  101.411402]  call_netdevice_notifiers+0xc/0xe
      [  101.412713]  rollback_registered_many+0x268/0x36e
      [  101.413702]  rollback_registered+0x39/0x56
      [  101.414965]  unregister_netdevice_queue+0x79/0x88
      [  101.415908]  unregister_netdev+0x16/0x1d
      
      Fixes: ceed73a2 ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation")
      Signed-off-by: NSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Reported-by: Nkernel test robot <xiaolong.ye@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c346525
    • C
      cnic: Fix an error handling path in 'cnic_alloc_bnx2x_resc()' · 05cf97e7
      Christophe JAILLET 提交于
      All the error handling paths 'goto error', except this one.
      We should also go to error in this case, or some resources will be
      leaking.
      Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05cf97e7
  6. 22 9月, 2017 8 次提交
  7. 21 9月, 2017 13 次提交
  8. 20 9月, 2017 7 次提交