1. 29 3月, 2011 1 次提交
  2. 22 3月, 2011 1 次提交
    • W
      xfrm: Fix initialize repl field of struct xfrm_state · a454f0cc
      Wei Yongjun 提交于
      Commit 'xfrm: Move IPsec replay detection functions to a separate file'
        (9fdc4883)
      introduce repl field to struct xfrm_state, and only initialize it
      under SA's netlink create path, the other path, such as pf_key,
      ipcomp/ipcomp6 etc, the repl field remaining uninitialize. So if
      the SA is created by pf_key, any input packet with SA's encryption
      algorithm will cause panic.
      
          int xfrm_input()
          {
              ...
              x->repl->advance(x, seq);
              ...
          }
      
      This patch fixed it by introduce new function __xfrm_init_state().
      
      Pid: 0, comm: swapper Not tainted 2.6.38-next+ #14 Bochs Bochs
      EIP: 0060:[<c078e5d5>] EFLAGS: 00010206 CPU: 0
      EIP is at xfrm_input+0x31c/0x4cc
      EAX: dd839c00 EBX: 00000084 ECX: 00000000 EDX: 01000000
      ESI: dd839c00 EDI: de3a0780 EBP: dec1de88 ESP: dec1de64
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process swapper (pid: 0, ti=dec1c000 task=c09c0f20 task.ti=c0992000)
      Stack:
       00000000 00000000 00000002 c0ba27c0 00100000 01000000 de3a0798 c0ba27c0
       00000033 dec1de98 c0786848 00000000 de3a0780 dec1dea4 c0786868 00000000
       dec1debc c074ee56 e1da6b8c de3a0780 c074ed44 de3a07a8 dec1decc c074ef32
      Call Trace:
       [<c0786848>] xfrm4_rcv_encap+0x22/0x27
       [<c0786868>] xfrm4_rcv+0x1b/0x1d
       [<c074ee56>] ip_local_deliver_finish+0x112/0x1b1
       [<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
       [<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
       [<c074ef77>] ip_local_deliver+0x3e/0x44
       [<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
       [<c074ec03>] ip_rcv_finish+0x30a/0x332
       [<c074e8f9>] ? ip_rcv_finish+0x0/0x332
       [<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
       [<c074f188>] ip_rcv+0x20b/0x247
       [<c074e8f9>] ? ip_rcv_finish+0x0/0x332
       [<c072797d>] __netif_receive_skb+0x373/0x399
       [<c0727bc1>] netif_receive_skb+0x4b/0x51
       [<e0817e2a>] cp_rx_poll+0x210/0x2c4 [8139cp]
       [<c072818f>] net_rx_action+0x9a/0x17d
       [<c0445b5c>] __do_softirq+0xa1/0x149
       [<c0445abb>] ? __do_softirq+0x0/0x149
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a454f0cc
  3. 14 3月, 2011 4 次提交
  4. 13 3月, 2011 3 次提交
  5. 02 3月, 2011 1 次提交
  6. 28 2月, 2011 4 次提交
  7. 24 2月, 2011 12 次提交
  8. 23 2月, 2011 8 次提交
  9. 09 2月, 2011 1 次提交
    • N
      ipsec: allow to align IPv4 AH on 32 bits · fa9921e4
      Nicolas Dichtel 提交于
      The Linux IPv4 AH stack aligns the AH header on a 64 bit boundary
      (like in IPv6). This is not RFC compliant (see RFC4302, Section
      3.3.3.2.1), it should be aligned on 32 bits.
      
      For most of the authentication algorithms, the ICV size is 96 bits.
      The AH header alignment on 32 or 64 bits gives the same results.
      
      However for SHA-256-128 for instance, the wrong 64 bit alignment results
      in adding useless padding in IPv4 AH, which is forbidden by the RFC.
      
      To avoid breaking backward compatibility, we use a new flag
      (XFRM_STATE_ALIGN4) do change original behavior.
      
      Initial patch from Dang Hongwu <hongwu.dang@6wind.com> and
      Christophe Gouault <christophe.gouault@6wind.com>.
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa9921e4
  10. 11 12月, 2010 1 次提交
  11. 29 11月, 2010 1 次提交
  12. 16 11月, 2010 1 次提交
  13. 28 10月, 2010 1 次提交
  14. 26 10月, 2010 1 次提交