1. 18 Jul, 2010 1 commit
    • Arnaud Ebalard's avatar
      IPv6: fix CoA check in RH2 input handler (mip6_rthdr_input()) · d9a9dc66
      Arnaud Ebalard authored
      The input handler for Type 2 Routing Header (mip6_rthdr_input())
      checks if the CoA in the packet matches the CoA in the XFRM state.
      
      Current check is buggy: it compares the adddress in the Type 2
      Routing Header, i.e. the HoA, against the expected CoA in the state.
      The comparison should be made against the address in the destination
      field of the IPv6 header.
      
      The bug remained unnoticed because the main (and possibly only current)
      user of the code (UMIP MIPv6 Daemon) initializes the XFRM state with the
      unspecified address, i.e. explicitly allows everything.
      
      Yoshifuji-san, can you ack that one?
      Signed-off-by: default avatarArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9a9dc66
  2. 16 Jul, 2010 4 commits
  3. 15 Jul, 2010 3 commits
    • Michael S. Tsirkin's avatar
      vhost-net: avoid flush under lock · 1680e906
      Michael S. Tsirkin authored
      We flush under vq mutex when changing backends.
      This creates a deadlock as workqueue being flushed
      needs this lock as well.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=612421
      
      Drop the vq mutex before flush: we have the device mutex
      which is sufficient to prevent another ioctl from touching
      the vq.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      1680e906
    • Tom Herbert's avatar
      net: fix problem in reading sock TX queue · b0f77d0e
      Tom Herbert authored
      Fix problem in reading the tx_queue recorded in a socket.  In
      dev_pick_tx, the TX queue is read by doing a check with
      sk_tx_queue_recorded on the socket, followed by a sk_tx_queue_get.
      The problem is that there is not mutual exclusion across these
      calls in the socket so it it is possible that the queue in the
      sock can be invalidated after sk_tx_queue_recorded is called so
      that sk_tx_queue get returns -1, which sets 65535 in queue_index
      and thus dev_pick_tx returns 65536 which is a bogus queue and
      can cause crash in dev_queue_xmit.
      
      We fix this by only calling sk_tx_queue_get which does the proper
      checks.  The interface is that sk_tx_queue_get returns the TX queue
      if the sock argument is non-NULL and TX queue is recorded, else it
      returns -1.  sk_tx_queue_recorded is no longer used so it can be
      completely removed.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0f77d0e
    • Doug Kehn's avatar
      net/core: neighbour update Oops · 91a72a70
      Doug Kehn authored
      When configuring DMVPN (GRE + openNHRP) and a GRE remote
      address is configured a kernel Oops is observed.  The
      obserseved Oops is caused by a NULL header_ops pointer
      (neigh->dev->header_ops) in neigh_update_hhs() when
      
      void (*update)(struct hh_cache*, const struct net_device*, const unsigned char *)
      = neigh->dev->header_ops->cache_update;
      
      is executed.  The dev associated with the NULL header_ops is
      the GRE interface.  This patch guards against the
      possibility that header_ops is NULL.
      
      This Oops was first observed in kernel version 2.6.26.8.
      Signed-off-by: default avatarDoug Kehn <rdkehn@yahoo.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      91a72a70
  4. 14 Jul, 2010 3 commits
  5. 13 Jul, 2010 3 commits
  6. 12 Jul, 2010 2 commits
  7. 09 Jul, 2010 1 commit
  8. 08 Jul, 2010 3 commits
  9. 07 Jul, 2010 5 commits
  10. 06 Jul, 2010 3 commits
  11. 04 Jul, 2010 1 commit
  12. 03 Jul, 2010 11 commits