1. 10 7月, 2008 9 次提交
  2. 08 7月, 2008 1 次提交
  3. 02 6月, 2008 1 次提交
    • A
      [CRYPTO] cts: Init SG tables · c4913c7b
      Alexey Dobriyan 提交于
      Steps to reproduce:
      
      	modprobe tcrypt		# with CONFIG_DEBUG_SG=y
      
      testing cts(cbc(aes)) encryption
      test 1 (128 bit key):
      ------------[ cut here ]------------
      kernel BUG at include/linux/scatterlist.h:65!
      invalid opcode: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
      CPU 0 
      Modules linked in: tea xts twofish twofish_common tcrypt(+) [maaaany]
      Pid: 16151, comm: modprobe Not tainted 2.6.26-rc4-fat #7
      RIP: 0010:[<ffffffffa0bf032e>]  [<ffffffffa0bf032e>] :cts:cts_cbc_encrypt+0x151/0x355
      RSP: 0018:ffff81016f497a88  EFLAGS: 00010286
      RAX: ffffe20009535d58 RBX: ffff81016f497af0 RCX: 0000000087654321
      RDX: ffff8100010d4f28 RSI: ffff81016f497ee8 RDI: ffff81016f497ac0
      RBP: ffff81016f497c38 R08: 0000000000000000 R09: 0000000000000011
      R10: ffffffff00000008 R11: ffff8100010d4f28 R12: ffff81016f497ac0
      R13: ffff81016f497b30 R14: 0000000000000010 R15: 0000000000000010
      FS:  00007fac6fa276f0(0000) GS:ffffffff8060e000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00007f12ca7cc000 CR3: 000000016f441000 CR4: 00000000000026e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
      Process modprobe (pid: 16151, threadinfo ffff81016f496000, task ffff8101755b4ae0)
      Stack:  0000000000000001 ffff81016f496000 ffffffff80719f78 0000000000000001
       0000000000000001 ffffffff8020c87c ffff81016f99c918 20646c756f772049
       65687420656b696c 0000000000000020 0000000000000000 0000000033341102
      Call Trace:
       [<ffffffff8020c87c>] ? restore_args+0x0/0x30
       [<ffffffffa04aa311>] ? :aes_generic:crypto_aes_expand_key+0x311/0x369
       [<ffffffff802ab453>] ? check_object+0x15a/0x213
       [<ffffffff802aad22>] ? init_object+0x6e/0x76
       [<ffffffff802ac3ae>] ? __slab_free+0xfc/0x371
       [<ffffffffa0bf05ed>] :cts:crypto_cts_encrypt+0xbb/0xca
       [<ffffffffa07108de>] ? :crypto_blkcipher:setkey+0xc7/0xec
       [<ffffffffa07110b8>] :crypto_blkcipher:async_encrypt+0x38/0x3a
       [<ffffffffa2ce9341>] :tcrypt:test_cipher+0x261/0x7c6
       [<ffffffffa2cfd9df>] :tcrypt:tcrypt_mod_init+0x9df/0x1b30
       [<ffffffff80261e35>] sys_init_module+0x9e/0x1b2
       [<ffffffff8020c15a>] system_call_after_swapgs+0x8a/0x8f
      Code: 45 c0 e8 aa 24 63 df 48 c1 e8 0c 48 b9 00 00 00 00 00 e2 ff ff 48 8b 55 88 48 6b c0 68 48 01 c8 b9 21 43 65 87 48 39 4d 80 74 04 <0f> 0b eb fe f6 c2 01 74 04 0f 0b eb fe 83 e2 03 4c 89 ef 44 89 
      RIP  [<ffffffffa0bf032e>] :cts:cts_cbc_encrypt+0x151/0x355
       RSP <ffff81016f497a88>
      ---[ end trace e8bahiarjand37fd ]---
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c4913c7b
  4. 07 5月, 2008 1 次提交
    • H
      [CRYPTO] hmac: Avoid calling virt_to_page on key · 67412f0e
      Herbert Xu 提交于
      When HMAC gets a key longer than the block size of the hash, it needs
      to feed it as input to the hash to reduce it to a fixed length.  As
      it is HMAC converts the key to a scatter and gather list.  However,
      this doesn't work on certain platforms if the key is not allocated
      via kmalloc.  For example, the keys from tcrypt are stored in the
      rodata section and this causes it to fail with HMAC on x86-64.
      
      This patch fixes this by copying the key to memory obtained via
      kmalloc before hashing it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      67412f0e
  5. 01 5月, 2008 3 次提交
    • J
      [CRYPTO] cryptd: Correct kzalloc error test · b1145ce3
      Julia Lawall 提交于
      Normally, kzalloc returns NULL or a valid pointer value, not a value to be
      tested using IS_ERR.
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      b1145ce3
    • H
      [CRYPTO] eseqiv: Fix off-by-one encryption · 46f8153c
      Herbert Xu 提交于
      After attaching the IV to the head during encryption, eseqiv does not
      increase the encryption length by that amount.  As such the last block
      of the actual plain text will be left unencrypted.
      
      Fortunately the only user of this code hifn currently crashes so this
      shouldn't affect anyone :)
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      46f8153c
    • P
      [CRYPTO] authenc: Fix async crypto crash in crypto_authenc_genicv() · 16161329
      Patrick McHardy 提交于
      crypto_authenc_givencrypt_done uses req->data as struct aead_givcrypt_request,
      while it really points to a struct aead_request, causing this crash:
      
      BUG: unable to handle kernel paging request at 6b6b6b6b
      IP: [<dc87517b>] :authenc:crypto_authenc_genicv+0x23/0x109
      *pde = 00000000
      Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
      Modules linked in: hifn_795x authenc esp4 aead xfrm4_mode_tunnel sha1_generic hmac crypto_hash]
      
      Pid: 3074, comm: ping Not tainted (2.6.25 #4)
      EIP: 0060:[<dc87517b>] EFLAGS: 00010296 CPU: 0
      EIP is at crypto_authenc_genicv+0x23/0x109 [authenc]
      EAX: daa04690 EBX: daa046e0 ECX: dab0a100 EDX: daa046b0
      ESI: 6b6b6b6b EDI: dc872054 EBP: c033ff60 ESP: c033ff0c
       DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      Process ping (pid: 3074, ti=c033f000 task=db883a80 task.ti=dab6c000)
      Stack: 00000000 daa046b0 c0215a3e daa04690 dab0a100 00000000 ffffffff db9fd7f0
             dba208c0 dbbb1720 00000001 daa04720 00000001 c033ff54 c0119ca9 dc852a75
             c033ff60 c033ff60 daa046e0 00000000 00000001 c033ff6c dc87527b 00000001
      Call Trace:
       [<c0215a3e>] ? dev_alloc_skb+0x14/0x29
       [<c0119ca9>] ? printk+0x15/0x17
       [<dc87527b>] ? crypto_authenc_givencrypt_done+0x1a/0x27 [authenc]
       [<dc850cca>] ? hifn_process_ready+0x34a/0x352 [hifn_795x]
       [<dc8353c7>] ? rhine_napipoll+0x3f2/0x3fd [via_rhine]
       [<dc851a56>] ? hifn_check_for_completion+0x4d/0xa6 [hifn_795x]
       [<dc851ab9>] ? hifn_tasklet_callback+0xa/0xc [hifn_795x]
       [<c011d046>] ? tasklet_action+0x3f/0x66
       [<c011d230>] ? __do_softirq+0x38/0x7a
       [<c0105a5f>] ? do_softirq+0x3e/0x71
       [<c011d17c>] ? irq_exit+0x2c/0x65
       [<c010e0c0>] ? smp_apic_timer_interrupt+0x5f/0x6a
       [<c01042e4>] ? apic_timer_interrupt+0x28/0x30
       [<dc851640>] ? hifn_handle_req+0x44a/0x50d [hifn_795x]
       ...
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      16161329
  6. 21 4月, 2008 14 次提交
  7. 18 4月, 2008 2 次提交
  8. 02 4月, 2008 1 次提交
    • J
      [CRYPTO] xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk · 1edcf2e1
      Joy Latten 提交于
      The kernel crashes when ipsec passes a udp packet of about 14XX bytes
      of data to aes-xcbc-mac.
      
      It seems the first xxxx bytes of the data are in first sg entry,
      and remaining xx bytes are in next sg entry. But we don't 
      check next sg entry to see if we need to go look the page up.
      
      I noticed in hmac.c, we do a scatterwalk_sg_next(), to do this check
      and possible lookup, thus xcbc.c needs to use this routine too.
      
      A 15-hour run of an ipsec stress test sending streams of tcp and
      udp packets of various sizes,  using this patch and 
      aes-xcbc-mac completed successfully, so hopefully this fixes the
      problem.
      Signed-off-by: NJoy Latten <latten@austin.ibm.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      1edcf2e1
  9. 19 3月, 2008 1 次提交
  10. 14 3月, 2008 1 次提交
  11. 08 3月, 2008 1 次提交
  12. 06 3月, 2008 2 次提交
  13. 05 3月, 2008 1 次提交
  14. 23 2月, 2008 2 次提交