1. 14 4月, 2017 2 次提交
  2. 15 2月, 2017 4 次提交
  3. 09 2月, 2017 1 次提交
  4. 30 1月, 2017 1 次提交
  5. 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
  6. 25 3月, 2016 1 次提交
    • S
      xfrm: Fix crash observed during device unregistration and decryption · 071d36bf
      subashab@codeaurora.org 提交于
      A crash is observed when a decrypted packet is processed in receive
      path. get_rps_cpus() tries to dereference the skb->dev fields but it
      appears that the device is freed from the poison pattern.
      
      [<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
      [<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
      [<ffffffc000af6094>] netif_rx+0x74/0x94
      [<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
      [<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
      [<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
      [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
      [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
      [<ffffffc0000bb40c>] kthread+0xe0/0xec
      
      -013|get_rps_cpu(
           |    dev = 0xFFFFFFC08B688000,
           |    skb = 0xFFFFFFC0C76AAC00 -> (
           |      dev = 0xFFFFFFC08B688000 -> (
           |        name =
      "......................................................
           |        name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
      0xAAAAAAAAAAA
      
      Following are the sequence of events observed -
      
      - Encrypted packet in receive path from netdevice is queued
      - Encrypted packet queued for decryption (asynchronous)
      - Netdevice brought down and freed
      - Packet is decrypted and returned through callback in esp_input_done
      - Packet is queued again for process in network stack using netif_rx
      
      Since the device appears to have been freed, the dereference of
      skb->dev in get_rps_cpus() leads to an unhandled page fault
      exception.
      
      Fix this by holding on to device reference when queueing packets
      asynchronously and releasing the reference on call back return.
      
      v2: Make the change generic to xfrm as mentioned by Steffen and
      update the title to xfrm
      Suggested-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NJerome Stanislaus <jeromes@codeaurora.org>
      Signed-off-by: NSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      071d36bf
  7. 23 10月, 2015 1 次提交
  8. 28 5月, 2015 1 次提交
  9. 24 4月, 2015 1 次提交
  10. 23 4月, 2015 1 次提交
  11. 07 4月, 2015 1 次提交
    • A
      xfrm: fix xfrm_input/xfrm_tunnel_check oops · 68c11e98
      Alexey Dobriyan 提交于
      https://bugzilla.kernel.org/show_bug.cgi?id=95211
      
      Commit 70be6c91
      ("xfrm: Add xfrm_tunnel_skb_cb to the skb common buffer") added check
      which dereferences ->outer_mode too early but larval SAs don't have
      this pointer set (yet). So check for tunnel stuff later.
      
      Mike Noordermeer reported this bug and patiently applied all the debugging.
      
      Technically this is remote-oops-in-interrupt-context type of thing.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000034
      IP: [<ffffffff8150dca2>] xfrm_input+0x3c2/0x5a0
      	...
      [<ffffffff81500fc6>] ? xfrm4_esp_rcv+0x36/0x70
      [<ffffffff814acc9a>] ? ip_local_deliver_finish+0x9a/0x200
      [<ffffffff81471b83>] ? __netif_receive_skb_core+0x6f3/0x8f0
      	...
      
      RIP  [<ffffffff8150dca2>] xfrm_input+0x3c2/0x5a0
      Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      68c11e98
  12. 14 3月, 2014 1 次提交
  13. 25 2月, 2014 2 次提交
  14. 02 1月, 2014 1 次提交
  15. 06 6月, 2013 1 次提交
    • F
      xfrm: add LINUX_MIB_XFRMACQUIREERROR statistic counter · 4c4d41f2
      Fan Du 提交于
      When host ping its peer, ICMP echo request packet triggers IPsec
      policy, then host negotiates SA secret with its peer. After IKE
      installed SA for OUT direction, but before SA for IN direction
      installed, host get ICMP echo reply from its peer. At the time
      being, the SA state for IN direction could be XFRM_STATE_ACQ,
      then the received packet will be dropped after adding
      LINUX_MIB_XFRMINSTATEINVALID statistic.
      
      Adding a LINUX_MIB_XFRMACQUIREERROR statistic counter for such
      scenario when SA in larval state is much clearer for user than
      LINUX_MIB_XFRMINSTATEINVALID which indicates the SA is totally
      bad.
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      4c4d41f2
  16. 05 9月, 2012 1 次提交
  17. 22 9月, 2011 1 次提交
  18. 29 3月, 2011 1 次提交
  19. 28 3月, 2011 1 次提交
  20. 14 3月, 2011 3 次提交
  21. 23 2月, 2010 1 次提交
  22. 03 6月, 2009 1 次提交
  23. 19 12月, 2008 1 次提交
  24. 05 12月, 2008 1 次提交
  25. 26 11月, 2008 3 次提交
  26. 25 3月, 2008 1 次提交
  27. 13 2月, 2008 1 次提交
  28. 01 2月, 2008 2 次提交
  29. 29 1月, 2008 2 次提交