Skip to content
Snippets Groups Projects
  1. May 01, 2018
    • Thomas Winter's avatar
      ipv6: Allow non-gateway ECMP for IPv6 · edd7ceb7
      Thomas Winter authored
      
      It is valid to have static routes where the nexthop
      is an interface not an address such as tunnels.
      For IPv4 it was possible to use ECMP on these routes
      but not for IPv6.
      
      Signed-off-by: default avatarThomas Winter <Thomas.Winter@alliedtelesis.co.nz>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      edd7ceb7
    • Wenwen Wang's avatar
      ethtool: fix a potential missing-check bug · d656fe49
      Wenwen Wang authored
      
      In ethtool_get_rxnfc(), the object "info" is firstly copied from
      user-space. If the FLOW_RSS flag is set in the member field flow_type of
      "info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from
      user-space because FLOW_RSS is newer and has new definition, as mentioned
      in the comment. However, given that the user data resides in user-space, a
      malicious user can race to change the data after the first copy. By doing
      so, the user can inject inconsistent data. For example, in the second
      copy, the FLOW_RSS flag could be cleared in the field flow_type of "info".
      In the following execution, "info" will be used in the function
      ops->get_rxnfc(). Such inconsistent data can potentially lead to unexpected
      information leakage since ops->get_rxnfc() will prepare various types of
      data according to flow_type, and the prepared data will be eventually
      copied to user-space. This inconsistent data may also cause undefined
      behaviors based on how ops->get_rxnfc() is implemented.
      
      This patch simply re-verifies the flow_type field of "info" after the
      second copy. If the value is not as expected, an error code will be
      returned.
      
      Signed-off-by: default avatarWenwen Wang <wang6495@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d656fe49
    • Colin Ian King's avatar
      net/mlx4: fix spelling mistake: "failedi" -> "failed" · 26ff7585
      Colin Ian King authored
      
      trivial fix to spelling mistake in mlx4_warn message.
      
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26ff7585
    • Michael S. Tsirkin's avatar
      vhost: make msg padding explicit · de08481a
      Michael S. Tsirkin authored
      
      There's a 32 bit hole just after type. It's best to
      give it a name, this way compiler is forced to initialize
      it with rest of the structure.
      
      Reported-by: default avatarKevin Easton <kevin@guarana.org>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de08481a
    • Eric Dumazet's avatar
      tcp: fix TCP_REPAIR_QUEUE bound checking · bf2acc94
      Eric Dumazet authored
      
      syzbot is able to produce a nasty WARN_ON() in tcp_verify_left_out()
      with following C-repro :
      
      socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
      setsockopt(3, SOL_TCP, TCP_REPAIR, [1], 4) = 0
      setsockopt(3, SOL_TCP, TCP_REPAIR_QUEUE, [-1], 4) = 0
      bind(3, {sa_family=AF_INET, sin_port=htons(20002), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
      sendto(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
      	1242, MSG_FASTOPEN, {sa_family=AF_INET, sin_port=htons(20002), sin_addr=inet_addr("127.0.0.1")}, 16) = 1242
      setsockopt(3, SOL_TCP, TCP_REPAIR_WINDOW, "\4\0\0@+\205\0\0\377\377\0\0\377\377\377\177\0\0\0\0", 20) = 0
      writev(3, [{"\270", 1}], 1)             = 1
      setsockopt(3, SOL_TCP, TCP_REPAIR_OPTIONS, "\10\0\0\0\0\0\0\0\0\0\0\0|\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 386) = 0
      writev(3, [{"\210v\r[\226\320t\231qwQ\204\264l\254\t\1\20\245\214p\350H\223\254;\\\37\345\307p$"..., 3144}], 1) = 3144
      
      The 3rd system call looks odd :
      setsockopt(3, SOL_TCP, TCP_REPAIR_QUEUE, [-1], 4) = 0
      
      This patch makes sure bound checking is using an unsigned compare.
      
      Fixes: ee995283 ("tcp: Initial repair mode")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf2acc94
    • Eric Dumazet's avatar
      ipv6: fix uninit-value in ip6_multipath_l3_keys() · cea67a2d
      Eric Dumazet authored
      
      syzbot/KMSAN reported an uninit-value in ip6_multipath_l3_keys(),
      root caused to a bad assumption of ICMP header being already
      pulled in skb->head
      
      ip_multipath_l3_keys() does the correct thing, so it is an IPv6 only bug.
      
      BUG: KMSAN: uninit-value in ip6_multipath_l3_keys net/ipv6/route.c:1830 [inline]
      BUG: KMSAN: uninit-value in rt6_multipath_hash+0x5c4/0x640 net/ipv6/route.c:1858
      CPU: 0 PID: 4507 Comm: syz-executor661 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
       ip6_multipath_l3_keys net/ipv6/route.c:1830 [inline]
       rt6_multipath_hash+0x5c4/0x640 net/ipv6/route.c:1858
       ip6_route_input+0x65a/0x920 net/ipv6/route.c:1884
       ip6_rcv_finish+0x413/0x6e0 net/ipv6/ip6_input.c:69
       NF_HOOK include/linux/netfilter.h:288 [inline]
       ipv6_rcv+0x1e16/0x2340 net/ipv6/ip6_input.c:208
       __netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4562
       __netif_receive_skb net/core/dev.c:4627 [inline]
       netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701
       netif_receive_skb+0x230/0x240 net/core/dev.c:4725
       tun_rx_batched drivers/net/tun.c:1555 [inline]
       tun_get_user+0x740f/0x7c60 drivers/net/tun.c:1962
       tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
       call_write_iter include/linux/fs.h:1782 [inline]
       new_sync_write fs/read_write.c:469 [inline]
       __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
       vfs_write+0x463/0x8d0 fs/read_write.c:544
       SYSC_write+0x172/0x360 fs/read_write.c:589
       SyS_write+0x55/0x80 fs/read_write.c:581
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      
      Fixes: 23aebdac ("ipv6: Compute multipath hash for ICMP errors from offending packet")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Jakub Sitnicki <jkbs@redhat.com>
      Acked-by: default avatarJakub Sitnicki <jkbs@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cea67a2d
  2. Apr 30, 2018
  3. Apr 28, 2018
  4. Apr 27, 2018
  5. Apr 26, 2018
  6. Apr 25, 2018
Loading