1. 15 Jan, 2019 1 commit
    • Ido Schimmel's avatar
      net: ipv4: Fix memory leak in network namespace dismantle · f97f4dd8
      Ido Schimmel authored
      IPv4 routing tables are flushed in two cases:
      
      1. In response to events in the netdev and inetaddr notification chains
      2. When a network namespace is being dismantled
      
      In both cases only routes associated with a dead nexthop group are
      flushed. However, a nexthop group will only be marked as dead in case it
      is populated with actual nexthops using a nexthop device. This is not
      the case when the route in question is an error route (e.g.,
      'blackhole', 'unreachable').
      
      Therefore, when a network namespace is being dismantled such routes are
      not flushed and leaked [1].
      
      To reproduce:
      # ip netns add blue
      # ip -n blue route add unreachable 192.0.2.0/24
      # ip netns del blue
      
      Fix this by not skipping error routes that are not marked with
      RTNH_F_DEAD when flushing the routing tables.
      
      To prevent the flushing of such routes in case #1, add a parameter to
      fib_table_flush() that indicates if the table is flushed as part of
      namespace dismantle or not.
      
      Note that this problem does not exist in IPv6 since error routes are
      associated with the loopback device.
      
      [1]
      unreferenced object 0xffff888066650338 (size 56):
        comm "ip", pid 1206, jiffies 4294786063 (age 26.235s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 b0 1c 62 61 80 88 ff ff  ..........ba....
          e8 8b a1 64 80 88 ff ff 00 07 00 08 fe 00 00 00  ...d............
        backtrace:
          [<00000000856ed27d>] inet_rtm_newroute+0x129/0x220
          [<00000000fcdfc00a>] rtnetlink_rcv_msg+0x397/0xa20
          [<00000000cb85801a>] netlink_rcv_skb+0x132/0x380
          [<00000000ebc991d2>] netlink_unicast+0x4c0/0x690
          [<0000000014f62875>] netlink_sendmsg+0x929/0xe10
          [<00000000bac9d967>] sock_sendmsg+0xc8/0x110
          [<00000000223e6485>] ___sys_sendmsg+0x77a/0x8f0
          [<000000002e94f880>] __sys_sendmsg+0xf7/0x250
          [<00000000ccb1fa72>] do_syscall_64+0x14d/0x610
          [<00000000ffbe3dae>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
          [<000000003a8b605b>] 0xffffffffffffffff
      unreferenced object 0xffff888061621c88 (size 48):
        comm "ip", pid 1206, jiffies 4294786063 (age 26.235s)
        hex dump (first 32 bytes):
          6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
          6b 6b 6b 6b 6b 6b 6b 6b d8 8e 26 5f 80 88 ff ff  kkkkkkkk..&_....
        backtrace:
          [<00000000733609e3>] fib_table_insert+0x978/0x1500
          [<00000000856ed27d>] inet_rtm_newroute+0x129/0x220
          [<00000000fcdfc00a>] rtnetlink_rcv_msg+0x397/0xa20
          [<00000000cb85801a>] netlink_rcv_skb+0x132/0x380
          [<00000000ebc991d2>] netlink_unicast+0x4c0/0x690
          [<0000000014f62875>] netlink_sendmsg+0x929/0xe10
          [<00000000bac9d967>] sock_sendmsg+0xc8/0x110
          [<00000000223e6485>] ___sys_sendmsg+0x77a/0x8f0
          [<000000002e94f880>] __sys_sendmsg+0xf7/0x250
          [<00000000ccb1fa72>] do_syscall_64+0x14d/0x610
          [<00000000ffbe3dae>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
          [<000000003a8b605b>] 0xffffffffffffffff
      
      Fixes: 8cced9ef ("[NETNS]: Enable routing configuration in non-initial namespace.")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f97f4dd8
  2. 16 Oct, 2018 1 commit
  3. 25 May, 2018 1 commit
  4. 16 May, 2018 2 commits
  5. 29 Mar, 2018 2 commits
  6. 26 Mar, 2018 1 commit
  7. 26 Feb, 2018 1 commit
  8. 16 Jan, 2018 1 commit
    • Alexey Dobriyan's avatar
      net: delete /proc THIS_MODULE references · 96890d62
      Alexey Dobriyan authored
      /proc has been ignoring struct file_operations::owner field for 10 years.
      Specifically, it started with commit 786d7e16
      ("Fix rmmod/read/write races in /proc entries"). Notice the chunk where
      inode->i_fop is initialized with proxy struct file_operations for
      regular files:
      
      	-               if (de->proc_fops)
      	-                       inode->i_fop = de->proc_fops;
      	+               if (de->proc_fops) {
      	+                       if (S_ISREG(inode->i_mode))
      	+                               inode->i_fop = &proc_reg_file_ops;
      	+                       else
      	+                               inode->i_fop = de->proc_fops;
      	+               }
      
      VFS stopped pinning module at this point.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96890d62
  9. 01 Nov, 2017 1 commit
  10. 20 Oct, 2017 1 commit
  11. 24 Aug, 2017 1 commit
    • Xin Long's avatar
      ipv4: do metrics match when looking up and deleting a route · 5f9ae3d9
      Xin Long authored
      Now when ipv4 route inserts a fib_info, it memcmp fib_metrics.
      It means ipv4 route identifies one route also with metrics.
      
      But when removing a route, it tries to find the route without
      caring about the metrics. It will cause that the route with
      right metrics can't be removed.
      
      Thomas noticed this issue when doing the testing:
      
      1. add:
         # ip route append 192.168.7.0/24 dev v window 1000
         # ip route append 192.168.7.0/24 dev v window 1001
         # ip route append 192.168.7.0/24 dev v window 1002
         # ip route append 192.168.7.0/24 dev v window 1003
      2. delete:
         # ip route delete 192.168.7.0/24 dev v window 1002
      3. show:
           192.168.7.0/24 proto boot scope link window 1001
           192.168.7.0/24 proto boot scope link window 1002
           192.168.7.0/24 proto boot scope link window 1003
      
      The one with window 1002 wasn't deleted but the first one was.
      
      This patch is to do metrics match when looking up and deleting
      one route.
      Reported-by: default avatarThomas Haller <thaller@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f9ae3d9
  12. 03 Aug, 2017 1 commit
    • Ido Schimmel's avatar
      net: core: Make the FIB notification chain generic · 04b1d4e5
      Ido Schimmel authored
      The FIB notification chain is currently soley used by IPv4 code.
      However, we're going to introduce IPv6 FIB offload support, which
      requires these notification as well.
      
      As explained in commit c3852ef7 ("ipv4: fib: Replay events when
      registering FIB notifier"), upon registration to the chain, the callee
      receives a full dump of the FIB tables and rules by traversing all the
      net namespaces. The integrity of the dump is ensured by a per-namespace
      sequence counter that is incremented whenever a change to the tables or
      rules occurs.
      
      In order to allow more address families to use the chain, each family is
      expected to register its fib_notifier_ops in its pernet init. These
      operations allow the common code to read the family's sequence counter
      as well as dump its tables and rules in the given net namespace.
      
      Additionally, a 'family' parameter is added to sent notifications, so
      that listeners could distinguish between the different families.
      
      Implement the common code that allows listeners to register to the chain
      and for address families to register their fib_notifier_ops. Subsequent
      patches will implement these operations in IPv6.
      
      In the future, ipmr and ip6mr will be extended to provide these
      notifications as well.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04b1d4e5
  13. 04 Jul, 2017 1 commit
  14. 30 May, 2017 3 commits
  15. 26 May, 2017 1 commit
  16. 22 May, 2017 1 commit
  17. 16 May, 2017 1 commit
    • David Ahern's avatar
      net: Improve handling of failures on link and route dumps · f6c5775f
      David Ahern authored
      In general, rtnetlink dumps do not anticipate failure to dump a single
      object (e.g., link or route) on a single pass. As both route and link
      objects have grown via more attributes, that is no longer a given.
      
      netlink dumps can handle a failure if the dump function returns an
      error; specifically, netlink_dump adds the return code to the response
      if it is <= 0 so userspace is notified of the failure. The missing
      piece is the rtnetlink dump functions returning the error.
      
      Fix route and link dump functions to return the errors if no object is
      added to an skb (detected by skb->len != 0). IPv6 route dumps
      (rt6_dump_route) already return the error; this patch updates IPv4 and
      link dumps. Other dump functions may need to be ajusted as well.
      Reported-by: default avatarJan Moskyto Matejka <mq@ucw.cz>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6c5775f
  18. 10 Mar, 2017 2 commits
  19. 28 Feb, 2017 1 commit
  20. 10 Feb, 2017 4 commits
  21. 24 Dec, 2016 1 commit
  22. 05 Dec, 2016 2 commits
  23. 04 Dec, 2016 3 commits
    • Ido Schimmel's avatar
      ipv4: fib: Replay events when registering FIB notifier · c3852ef7
      Ido Schimmel authored
      Commit b90eb754 ("fib: introduce FIB notification infrastructure")
      introduced a new notification chain to notify listeners (f.e., switchdev
      drivers) about addition and deletion of routes.
      
      However, upon registration to the chain the FIB tables can already be
      populated, which means potential listeners will have an incomplete view
      of the tables.
      
      Solve that by dumping the FIB tables and replaying the events to the
      passed notification block. The dump itself is done using RCU in order
      not to starve consumers that need RTNL to make progress.
      
      The integrity of the dump is ensured by reading the FIB change sequence
      counter before and after the dump under RTNL. This allows us to avoid
      the problematic situation in which the dumping process sends a ENTRY_ADD
      notification following ENTRY_DEL generated by another process holding
      RTNL.
      
      Callers of the registration function may pass a callback that is
      executed in case the dump was inconsistent with current FIB tables.
      
      The number of retries until a consistent dump is achieved is set to a
      fixed number to prevent callers from looping for long periods of time.
      In case current limit proves to be problematic in the future, it can be
      easily converted to be configurable using a sysctl.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3852ef7
    • Ido Schimmel's avatar
      ipv4: fib: Allow for consistent FIB dumping · cacaad11
      Ido Schimmel authored
      The next patch will enable listeners of the FIB notification chain to
      request a dump of the FIB tables. However, since RTNL isn't taken during
      the dump, it's possible for the FIB tables to change mid-dump, which
      will result in inconsistency between the listener's table and the
      kernel's.
      
      Allow listeners to know about changes that occurred mid-dump, by adding
      a change sequence counter to each net namespace. The counter is
      incremented just before a notification is sent in the FIB chain.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cacaad11
    • Ido Schimmel's avatar
      ipv4: fib: Convert FIB notification chain to be atomic · d3f706f6
      Ido Schimmel authored
      In order not to hold RTNL for long periods of time we're going to dump
      the FIB tables using RCU.
      
      Convert the FIB notification chain to be atomic, as we can't block in
      RCU critical sections.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3f706f6
  24. 16 Nov, 2016 2 commits
  25. 08 Nov, 2016 1 commit
    • Alexander Duyck's avatar
      fib_trie: Correct /proc/net/route off by one error · fd0285a3
      Alexander Duyck authored
      The display of /proc/net/route has had a couple issues due to the fact that
      when I originally rewrote most of fib_trie I made it so that the iterator
      was tracking the next value to use instead of the current.
      
      In addition it had an off by 1 error where I was tracking the first piece
      of data as position 0, even though in reality that belonged to the
      SEQ_START_TOKEN.
      
      This patch updates the code so the iterator tracks the last reported
      position and key instead of the next expected position and key.  In
      addition it shifts things so that all of the leaves start at 1 instead of
      trying to report leaves starting with offset 0 as being valid.  With these
      two issues addressed this should resolve any off by one errors that were
      present in the display of /proc/net/route.
      
      Fixes: 25b97c01 ("ipv4: off-by-one in continuation handling in /proc/net/route")
      Cc: Andy Whitcroft <apw@canonical.com>
      Reported-by: default avatarJason Baron <jbaron@akamai.com>
      Tested-by: default avatarJason Baron <jbaron@akamai.com>
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd0285a3
  26. 28 Sep, 2016 2 commits
  27. 09 Sep, 2016 1 commit
    • Guillaume Nault's avatar
      ipv4: fix value of ->nlmsg_flags reported in RTM_NEWROUTE events · b93e1fa7
      Guillaume Nault authored
      fib_table_insert() inconsistently fills the nlmsg_flags field in its
      notification messages.
      
      Since commit b8f55831 ("[RTNETLINK]: Fix sending netlink message
      when replace route."), the netlink message has its nlmsg_flags set to
      NLM_F_REPLACE if the route replaced a preexisting one.
      
      Then commit a2bb6d7d ("ipv4: include NLM_F_APPEND flag in append
      route notifications") started setting nlmsg_flags to NLM_F_APPEND if
      the route matched a preexisting one but was appended.
      
      In other cases (exclusive creation or prepend), nlmsg_flags is 0.
      
      This patch sets ->nlmsg_flags in all situations, preserving the
      semantic of the NLM_F_* bits:
      
        * NLM_F_CREATE: a new fib entry has been created for this route.
        * NLM_F_EXCL: no other fib entry existed for this route.
        * NLM_F_REPLACE: this route has overwritten a preexisting fib entry.
        * NLM_F_APPEND: the new fib entry was added after other entries for
          the same route.
      
      As a result, the possible flag combination can now be reported
      (iproute2's terminology into parentheses):
      
        * NLM_F_CREATE | NLM_F_EXCL: route didn't exist, exclusive creation
          ("add").
        * NLM_F_CREATE | NLM_F_APPEND: route did already exist, new route
          added after preexisting ones ("append").
        * NLM_F_CREATE: route did already exist, new route added before
          preexisting ones ("prepend").
        * NLM_F_REPLACE: route did already exist, new route replaced the
          first preexisting one ("change").
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b93e1fa7