1. 20 1月, 2019 2 次提交
  2. 05 1月, 2019 1 次提交
    • A
      netlink: fixup regression in RTM_GETADDR · 7c1e8a38
      Arthur Gautier 提交于
      This commit fixes a regression in AF_INET/RTM_GETADDR and
      AF_INET6/RTM_GETADDR.
      
      Before this commit, the kernel would stop dumping addresses once the first
      skb was full and end the stream with NLMSG_DONE(-EMSGSIZE). The error
      shouldn't be sent back to netlink_dump so the callback is kept alive. The
      userspace is expected to call back with a new empty skb.
      
      Changes from V1:
       - The error is not handled in netlink_dump anymore but rather in
         inet_dump_ifaddr and inet6_dump_addr directly as suggested by
         David Ahern.
      
      Fixes: d7e38611 ("net/ipv4: Put target net when address dump fails due to bad attributes")
      Fixes: 242afaa6 ("net/ipv6: Put target net when address dump fails due to bad attributes")
      
      Cc: David Ahern <dsahern@gmail.com>
      Cc: "David S . Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NArthur Gautier <baloo@gandi.net>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c1e8a38
  3. 31 12月, 2018 1 次提交
  4. 07 12月, 2018 1 次提交
  5. 24 11月, 2018 1 次提交
    • H
      net/ipv6: re-do dad when interface has IFF_NOARP flag change · 896585d4
      Hangbin Liu 提交于
      When we add a new IPv6 address, we should also join corresponding solicited-node
      multicast address, unless the interface has IFF_NOARP flag, as function
      addrconf_join_solict() did. But if we remove IFF_NOARP flag later, we do
      not do dad and add the mcast address. So we will drop corresponding neighbour
      discovery message that came from other nodes.
      
      A typical example is after creating a ipvlan with mode l3, setting up an ipv6
      address and changing the mode to l2. Then we will not be able to ping this
      address as the interface doesn't join related solicited-node mcast address.
      
      Fix it by re-doing dad when interface changed IFF_NOARP flag. Then we will add
      corresponding mcast group and check if there is a duplicate address on the
      network.
      Reported-by: NJianlin Shi <jishi@redhat.com>
      Reviewed-by: NStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      896585d4
  6. 26 10月, 2018 1 次提交
  7. 25 10月, 2018 1 次提交
  8. 23 10月, 2018 2 次提交
  9. 21 10月, 2018 1 次提交
    • D
      net/ipv6: Fix index counter for unicast addresses in in6_dump_addrs · 4ba4c566
      David Ahern 提交于
      The loop wants to skip previously dumped addresses, so loops until
      current index >= saved index. If the message fills it wants to save
      the index for the next address to dump - ie., the one that did not
      fit in the current message.
      
      Currently, it is incrementing the index counter before comparing to the
      saved index, and then the saved index is off by 1 - it assumes the
      current address is going to fit in the message.
      
      Change the index handling to increment only after a succesful dump.
      
      Fixes: 502a2ffd ("ipv6: convert idev_list to list macros")
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ba4c566
  10. 09 10月, 2018 5 次提交
  11. 22 9月, 2018 1 次提交
    • J
      net/ipv6: Display all addresses in output of /proc/net/if_inet6 · 86f9bd1f
      Jeff Barnhill 提交于
      The backend handling for /proc/net/if_inet6 in addrconf.c doesn't properly
      handle starting/stopping the iteration.  The problem is that at some point
      during the iteration, an overflow is detected and the process is
      subsequently stopped.  The item being shown via seq_printf() when the
      overflow occurs is not actually shown, though.  When start() is
      subsequently called to resume iterating, it returns the next item, and
      thus the item that was being processed when the overflow occurred never
      gets printed.
      
      Alter the meaning of the private data member "offset".  Currently, when it
      is not 0 (which only happens at the very beginning), "offset" represents
      the next hlist item to be printed.  After this change, "offset" always
      represents the current item.
      
      This is also consistent with the private data member "bucket", which
      represents the current bucket, and also the use of "pos" as defined in
      seq_file.txt:
          The pos passed to start() will always be either zero, or the most
          recent pos used in the previous session.
      Signed-off-by: NJeff Barnhill <0xeffeff@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86f9bd1f
  12. 20 9月, 2018 1 次提交
  13. 06 9月, 2018 2 次提交
    • C
      ipv6: add inet6_fill_args · 203651b6
      Christian Brauner 提交于
      inet6_fill_if{addr,mcaddr, acaddr}() already took 6 arguments which
      meant the 7th argument would need to be pushed onto the stack on x86.
      Add a new struct inet6_fill_args which holds common information passed
      to inet6_fill_if{addr,mcaddr, acaddr}() and shortens the functions to
      three pointer arguments.
      Signed-off-by: NChristian Brauner <christian@brauner.io>
      Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      203651b6
    • C
      ipv6: enable IFA_TARGET_NETNSID for RTM_GETADDR · 6ecf4c37
      Christian Brauner 提交于
      - Backwards Compatibility:
        If userspace wants to determine whether ipv6 RTM_GETADDR requests
        support the new IFA_TARGET_NETNSID property it should verify that the
        reply includes the IFA_TARGET_NETNSID property. If it does not
        userspace should assume that IFA_TARGET_NETNSID is not supported for
        ipv6 RTM_GETADDR requests on this kernel.
      - From what I gather from current userspace tools that make use of
        RTM_GETADDR requests some of them pass down struct ifinfomsg when they
        should actually pass down struct ifaddrmsg. To not break existing
        tools that pass down the wrong struct we will do the same as for
        RTM_GETLINK | NLM_F_DUMP requests and not error out when the
        nlmsg_parse() fails.
      
      - Security:
        Callers must have CAP_NET_ADMIN in the owning user namespace of the
        target network namespace.
      Signed-off-by: NChristian Brauner <christian@brauner.io>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ecf4c37
  14. 23 8月, 2018 1 次提交
  15. 24 7月, 2018 1 次提交
    • W
      ipv6: use fib6_info_hold_safe() when necessary · e873e4b9
      Wei Wang 提交于
      In the code path where only rcu read lock is held, e.g. in the route
      lookup code path, it is not safe to directly call fib6_info_hold()
      because the fib6_info may already have been deleted but still exists
      in the rcu grace period. Holding reference to it could cause double
      free and crash the kernel.
      
      This patch adds a new function fib6_info_hold_safe() and replace
      fib6_info_hold() in all necessary places.
      
      Syzbot reported 3 crash traces because of this. One of them is:
      8021q: adding VLAN 0 to HW filter on device team0
      IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready
      dst_release: dst:(____ptrval____) refcnt:-1
      dst_release: dst:(____ptrval____) refcnt:-2
      WARNING: CPU: 1 PID: 4845 at include/net/dst.h:239 dst_hold include/net/dst.h:239 [inline]
      WARNING: CPU: 1 PID: 4845 at include/net/dst.h:239 ip6_setup_cork+0xd66/0x1830 net/ipv6/ip6_output.c:1204
      dst_release: dst:(____ptrval____) refcnt:-1
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 4845 Comm: syz-executor493 Not tainted 4.18.0-rc3+ #10
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
       panic+0x238/0x4e7 kernel/panic.c:184
      dst_release: dst:(____ptrval____) refcnt:-2
      dst_release: dst:(____ptrval____) refcnt:-3
       __warn.cold.8+0x163/0x1ba kernel/panic.c:536
      dst_release: dst:(____ptrval____) refcnt:-4
       report_bug+0x252/0x2d0 lib/bug.c:186
       fixup_bug arch/x86/kernel/traps.c:178 [inline]
       do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
      dst_release: dst:(____ptrval____) refcnt:-5
       do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
       invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
      RIP: 0010:dst_hold include/net/dst.h:239 [inline]
      RIP: 0010:ip6_setup_cork+0xd66/0x1830 net/ipv6/ip6_output.c:1204
      Code: c1 ed 03 89 9d 18 ff ff ff 48 b8 00 00 00 00 00 fc ff df 41 c6 44 05 00 f8 e9 2d 01 00 00 4c 8b a5 c8 fe ff ff e8 1a f6 e6 fa <0f> 0b e9 6a fc ff ff e8 0e f6 e6 fa 48 8b 85 d0 fe ff ff 48 8d 78
      RSP: 0018:ffff8801a8fcf178 EFLAGS: 00010293
      RAX: ffff8801a8eba5c0 RBX: 0000000000000000 RCX: ffffffff869511e6
      RDX: 0000000000000000 RSI: ffffffff869515b6 RDI: 0000000000000005
      RBP: ffff8801a8fcf2c8 R08: ffff8801a8eba5c0 R09: ffffed0035ac8338
      R10: ffffed0035ac8338 R11: ffff8801ad6419c3 R12: ffff8801a8fcf720
      R13: ffff8801a8fcf6a0 R14: ffff8801ad6419c0 R15: ffff8801ad641980
       ip6_make_skb+0x2c8/0x600 net/ipv6/ip6_output.c:1768
       udpv6_sendmsg+0x2c90/0x35f0 net/ipv6/udp.c:1376
       inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
       sock_sendmsg_nosec net/socket.c:641 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:651
       ___sys_sendmsg+0x51d/0x930 net/socket.c:2125
       __sys_sendmmsg+0x240/0x6f0 net/socket.c:2220
       __do_sys_sendmmsg net/socket.c:2249 [inline]
       __se_sys_sendmmsg net/socket.c:2246 [inline]
       __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2246
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x446ba9
      Code: e8 cc bb 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fb39a469da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
      RAX: ffffffffffffffda RBX: 00000000006dcc54 RCX: 0000000000446ba9
      RDX: 00000000000000b8 RSI: 0000000020001b00 RDI: 0000000000000003
      RBP: 00000000006dcc50 R08: 00007fb39a46a700 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 45c828efc7a64843
      R13: e6eeb815b9d8a477 R14: 5068caf6f713c6fc R15: 0000000000000001
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Kernel Offset: disabled
      Rebooting in 86400 seconds..
      
      Fixes: 93531c67 ("net/ipv6: separate handling of FIB entries from dst based routes")
      Reported-by: syzbot+902e2a1bcd4f7808cef5@syzkaller.appspotmail.com
      Reported-by: syzbot+8ae62d67f647abeeceb9@syzkaller.appspotmail.com
      Reported-by: syzbot+3f08feb14086930677d0@syzkaller.appspotmail.com
      Signed-off-by: NWei Wang <weiwan@google.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e873e4b9
  16. 12 7月, 2018 4 次提交
  17. 30 6月, 2018 1 次提交
  18. 12 6月, 2018 1 次提交
    • D
      net/ipv6: Ensure cfg is properly initialized in ipv6_create_tempaddr · 3f2d67b6
      David Ahern 提交于
      Valdis reported a BUG in ipv6_add_addr:
      
      [ 1820.832682] BUG: unable to handle kernel NULL pointer dereference at 0000000000000209
      [ 1820.832728] RIP: 0010:ipv6_add_addr+0x280/0xd10
      [ 1820.832732] Code: 49 8b 1f 0f 84 6a 0a 00 00 48 85 db 0f 84 4e 0a 00 00 48 8b 03 48 8b 53 08 49 89 45 00 49 8b 47 10
      49 89 55 08 48 85 c0 74 15 <48> 8b 50 08 48 8b 00 49 89 95 b8 01 00 00 49 89 85 b0 01 00 00 4c
      [ 1820.832847] RSP: 0018:ffffaa07c2fd7880 EFLAGS: 00010202
      [ 1820.832853] RAX: 0000000000000201 RBX: ffffaa07c2fd79b0 RCX: 0000000000000000
      [ 1820.832858] RDX: a4cfbfba2cbfa64c RSI: 0000000000000000 RDI: ffffffff8a8e9fa0
      [ 1820.832862] RBP: ffffaa07c2fd7920 R08: 000000000000017a R09: ffffffff8a555300
      [ 1820.832866] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888d18e71c00
      [ 1820.832871] R13: ffff888d0a9b1200 R14: 0000000000000000 R15: ffffaa07c2fd7980
      [ 1820.832876] FS:  00007faa51bdb800(0000) GS:ffff888d1d400000(0000) knlGS:0000000000000000
      [ 1820.832880] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1820.832885] CR2: 0000000000000209 CR3: 000000021e8f8001 CR4: 00000000001606e0
      [ 1820.832888] Call Trace:
      [ 1820.832898]  ? __local_bh_enable_ip+0x119/0x260
      [ 1820.832904]  ? ipv6_create_tempaddr+0x259/0x5a0
      [ 1820.832912]  ? __local_bh_enable_ip+0x139/0x260
      [ 1820.832921]  ipv6_create_tempaddr+0x2da/0x5a0
      [ 1820.832926]  ? ipv6_create_tempaddr+0x2da/0x5a0
      [ 1820.832941]  manage_tempaddrs+0x1a5/0x240
      [ 1820.832951]  inet6_addr_del+0x20b/0x3b0
      [ 1820.832959]  ? nla_parse+0xce/0x1e0
      [ 1820.832968]  inet6_rtm_deladdr+0xd9/0x210
      [ 1820.832981]  rtnetlink_rcv_msg+0x1d4/0x5f0
      
      Looking at the code I found 1 element (peer_pfx) of the newly introduced
      ifa6_config struct that is not initialized. Use a memset rather than hard
      coding an init for each struct element.
      Reported-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Fixes: e6464b8c ("net/ipv6: Convert ipv6_add_addr to struct ifa6_config")
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f2d67b6
  19. 05 6月, 2018 1 次提交
  20. 29 5月, 2018 4 次提交
  21. 16 5月, 2018 1 次提交
  22. 26 4月, 2018 1 次提交
  23. 20 4月, 2018 4 次提交
  24. 18 4月, 2018 1 次提交