1. 15 2月, 2017 2 次提交
  2. 21 9月, 2016 1 次提交
    • N
      vti6: fix input path · 63c43787
      Nicolas Dichtel 提交于
      Since commit 1625f452, vti6 is broken, all input packets are dropped
      (LINUX_MIB_XFRMINNOSTATES is incremented).
      
      XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip6 is set by vti6_rcv() before calling
      xfrm6_rcv()/xfrm6_rcv_spi(), thus we cannot set to NULL that value in
      xfrm6_rcv_spi().
      
      A new function xfrm6_rcv_tnl() that enables to pass a value to
      xfrm6_rcv_spi() is added, so that xfrm6_rcv() is not touched (this function
      is used in several handlers).
      
      CC: Alexey Kodanev <alexey.kodanev@oracle.com>
      Fixes: 1625f452 ("net/xfrm_input: fix possible NULL deref of tunnel.ip6->parms.i_key")
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      63c43787
  3. 11 8月, 2016 1 次提交
    • A
      net/xfrm_input: fix possible NULL deref of tunnel.ip6->parms.i_key · 1625f452
      Alexey Kodanev 提交于
      Running LTP 'icmp-uni-basic.sh -6 -p ipcomp -m tunnel' test over
      openvswitch + veth can trigger kernel panic:
      
        BUG: unable to handle kernel NULL pointer dereference
        at 00000000000000e0 IP: [<ffffffff8169d1d2>] xfrm_input+0x82/0x750
        ...
        [<ffffffff816d472e>] xfrm6_rcv_spi+0x1e/0x20
        [<ffffffffa082c3c2>] xfrm6_tunnel_rcv+0x42/0x50 [xfrm6_tunnel]
        [<ffffffffa082727e>] tunnel6_rcv+0x3e/0x8c [tunnel6]
        [<ffffffff8169f365>] ip6_input_finish+0xd5/0x430
        [<ffffffff8169fc53>] ip6_input+0x33/0x90
        [<ffffffff8169f1d5>] ip6_rcv_finish+0xa5/0xb0
        ...
      
      It seems that tunnel.ip6 can have garbage values and also dereferenced
      without a proper check, only tunnel.ip4 is being verified. Fix it by
      adding one more if block for AF_INET6 and initialize tunnel.ip6 with NULL
      inside xfrm6_rcv_spi() (which is similar to xfrm4_rcv_spi()).
      
      Fixes: 049f8e2e ("xfrm: Override skb->mark with tunnel->parm.i_key in xfrm_input")
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      1625f452
  4. 18 9月, 2015 1 次提交
    • E
      netfilter: Pass struct net into the netfilter hooks · 29a26a56
      Eric W. Biederman 提交于
      Pass a network namespace parameter into the netfilter hooks.  At the
      call site of the netfilter hooks the path a packet is taking through
      the network stack is well known which allows the network namespace to
      be easily and reliabily.
      
      This allows the replacement of magic code like
      "dev_net(state->in?:state->out)" that appears at the start of most
      netfilter hooks with "state->net".
      
      In almost all cases the network namespace passed in is derived
      from the first network device passed in, guaranteeing those
      paths will not see any changes in practice.
      
      The exceptions are:
      xfrm/xfrm_output.c:xfrm_output_resume()         xs_net(skb_dst(skb)->xfrm)
      ipvs/ip_vs_xmit.c:ip_vs_nat_send_or_cont()      ip_vs_conn_net(cp)
      ipvs/ip_vs_xmit.c:ip_vs_send_or_cont()          ip_vs_conn_net(cp)
      ipv4/raw.c:raw_send_hdrinc()                    sock_net(sk)
      ipv6/ip6_output.c:ip6_xmit()			sock_net(sk)
      ipv6/ndisc.c:ndisc_send_skb()                   dev_net(skb->dev) not dev_net(dst->dev)
      ipv6/raw.c:raw6_send_hdrinc()                   sock_net(sk)
      br_netfilter_hooks.c:br_nf_pre_routing_finish() dev_net(skb->dev) before skb->dev is set to nf_bridge->physindev
      
      In all cases these exceptions seem to be a better expression for the
      network namespace the packet is being processed in then the historic
      "dev_net(in?in:out)".  I am documenting them in case something odd
      pops up and someone starts trying to track down what happened.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29a26a56
  5. 08 4月, 2015 1 次提交
    • D
      netfilter: Pass socket pointer down through okfn(). · 7026b1dd
      David Miller 提交于
      On the output paths in particular, we have to sometimes deal with two
      socket contexts.  First, and usually skb->sk, is the local socket that
      generated the frame.
      
      And second, is potentially the socket used to control a tunneling
      socket, such as one the encapsulates using UDP.
      
      We do not want to disassociate skb->sk when encapsulating in order
      to fix this, because that would break socket memory accounting.
      
      The most extreme case where this can cause huge problems is an
      AF_PACKET socket transmitting over a vxlan device.  We hit code
      paths doing checks that assume they are dealing with an ipv4
      socket, but are actually operating upon the AF_PACKET one.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7026b1dd
  6. 25 8月, 2014 2 次提交
  7. 25 3月, 2010 1 次提交
  8. 23 2月, 2010 1 次提交
  9. 26 11月, 2008 2 次提交
  10. 25 3月, 2008 1 次提交
  11. 29 1月, 2008 10 次提交
  12. 18 10月, 2007 4 次提交
    • H
      [IPSEC]: Rename mode to outer_mode and add inner_mode · 13996378
      Herbert Xu 提交于
      This patch adds a new field to xfrm states called inner_mode.  The existing
      mode object is renamed to outer_mode.
      
      This is the first part of an attempt to fix inter-family transforms.  As it
      is we always use the outer family when determining which mode to use.  As a
      result we may end up shoving IPv4 packets into netfilter6 and vice versa.
      
      What we really want is to use the inner family for the first part of outbound
      processing and the outer family for the second part.  For inbound processing
      we'd use the opposite pairing.
      
      I've also added a check to prevent silly combinations such as transport mode
      with inter-family transforms.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13996378
    • H
      [IPSEC]: Add missing BEET checks · 1bfcb10f
      Herbert Xu 提交于
      Currently BEET mode does not reinject the packet back into the stack
      like tunnel mode does.  Since BEET should behave just like tunnel mode
      this is incorrect.
      
      This patch fixes this by introducing a flags field to xfrm_mode that
      tells the IPsec code whether it should terminate and reinject the packet
      back into the stack.
      
      It then sets the flag for BEET and tunnel mode.
      
      I've also added a number of missing BEET checks elsewhere where we check
      whether a given mode is a tunnel or not.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bfcb10f
    • H
      [IPSEC]: Move ip_summed zapping out of xfrm6_rcv_spi · 7aa68cb9
      Herbert Xu 提交于
      Not every transform needs to zap ip_summed.  For example, a pure tunnel
      mode encapsulation does not affect the hardware checksum at all.  In fact,
      every algorithm (that needs this) other than AH6 already does its own
      ip_summed zapping.
      
      This patch moves the zapping into AH6 which is in line with what IPv4 does.
      
      Possible future optimisation: Checksum the data as we copy them in IPComp.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7aa68cb9
    • H
      [IPSEC]: Get nexthdr from caller in xfrm6_rcv_spi · 33b5ecb8
      Herbert Xu 提交于
      Currently xfrm6_rcv_spi gets the nexthdr value itself from the packet.
      This means that we need to fix up the value in case we have a 4-on-6
      tunnel.  Moving this logic into the caller simplifies things and allows
      us to merge the code with IPv4.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33b5ecb8
  13. 16 10月, 2007 1 次提交
  14. 31 5月, 2007 1 次提交
  15. 26 4月, 2007 4 次提交
  16. 14 2月, 2007 1 次提交
  17. 11 2月, 2007 1 次提交
  18. 29 9月, 2006 2 次提交
  19. 23 9月, 2006 2 次提交
  20. 18 6月, 2006 1 次提交