linux/crypto, branch v2.6.26

crypto: chainiv - Invoke completion function

2008-07-10T12:34:38Z

When chainiv postpones requests it never calls their completion functions. This causes symptoms such as memory leaks when IPsec is in use. Signed-off-by: Herbert Xu

crypto: tcrypt - Fix memory leak in test_cipher

2008-07-08T07:51:44Z

Coverity CID: 2306 & 2307 RESOURCE_LEAK In the second for loop in test_cipher(), data is allocated space with kzalloc() and is only ever freed in an error case. Looking at this loop, data is written to this memory but nothing seems to read from it. So here is a patch removing the allocation, I think this is the right fix. Only compile tested. Signed-off-by: Darren Jenkins Signed-off-by: Herbert Xu

[CRYPTO] cts: Init SG tables

2008-06-02T05:46:51Z

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:[] [] :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: [] ? restore_args+0x0/0x30 [] ? :aes_generic:crypto_aes_expand_key+0x311/0x369 [] ? check_object+0x15a/0x213 [] ? init_object+0x6e/0x76 [] ? __slab_free+0xfc/0x371 [] :cts:crypto_cts_encrypt+0xbb/0xca [] ? :crypto_blkcipher:setkey+0xc7/0xec [] :crypto_blkcipher:async_encrypt+0x38/0x3a [] :tcrypt:test_cipher+0x261/0x7c6 [] :tcrypt:tcrypt_mod_init+0x9df/0x1b30 [] sys_init_module+0x9e/0x1b2 [] 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 [] :cts:cts_cbc_encrypt+0x151/0x355 RSP ---[ end trace e8bahiarjand37fd ]--- Signed-off-by: Alexey Dobriyan Signed-off-by: Herbert Xu

[CRYPTO] hmac: Avoid calling virt_to_page on key

2008-05-07T13:08:56Z

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: Herbert Xu

[CRYPTO] cryptd: Correct kzalloc error test

2008-05-01T10:22:28Z

Normally, kzalloc returns NULL or a valid pointer value, not a value to be tested using IS_ERR. Signed-off-by: Julia Lawall Signed-off-by: Herbert Xu

[CRYPTO] eseqiv: Fix off-by-one encryption

2008-05-01T10:22:28Z

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: Herbert Xu

[CRYPTO] authenc: Fix async crypto crash in crypto_authenc_genicv()

2008-05-01T10:22:28Z

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: [] :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:[] 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: [] ? dev_alloc_skb+0x14/0x29 [] ? printk+0x15/0x17 [] ? crypto_authenc_givencrypt_done+0x1a/0x27 [authenc] [] ? hifn_process_ready+0x34a/0x352 [hifn_795x] [] ? rhine_napipoll+0x3f2/0x3fd [via_rhine] [] ? hifn_check_for_completion+0x4d/0xa6 [hifn_795x] [] ? hifn_tasklet_callback+0xa/0xc [hifn_795x] [] ? tasklet_action+0x3f/0x66 [] ? __do_softirq+0x38/0x7a [] ? do_softirq+0x3e/0x71 [] ? irq_exit+0x2c/0x65 [] ? smp_apic_timer_interrupt+0x5f/0x6a [] ? apic_timer_interrupt+0x28/0x30 [] ? hifn_handle_req+0x44a/0x50d [hifn_795x] ... Signed-off-by: Patrick McHardy Signed-off-by: Herbert Xu

[CRYPTO] kconfig: Ordering cleanup

2008-04-21T02:19:34Z

Ciphers, block modes, name it, are grouped together and sorted. Signed-off-by: Sebastian Siewior Signed-off-by: Herbert Xu

[CRYPTO] all: Clean up init()/fini()

2008-04-21T02:19:34Z

On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote: > Kamalesh Babulal wrote: > > > This patch cleanups the crypto code, replaces the init() and fini() > > with the _init/_fini > > This part ist OK. > > > or init/fini_ (if the > > _init/_fini exist) > > Having init_foo and foo_init won't be a good thing, will it? I'd start > confusing them. > > What about foo_modinit instead? Thanks for the suggestion, the init() is replaced with _mod_init () and fini () is replaced with _mod_fini. Signed-off-by: Kamalesh Babulal Signed-off-by: Herbert Xu

[CRYPTO] aes: Export generic setkey

2008-04-21T02:19:34Z

The key expansion routine could be get little more generic, become a kernel doc entry and then get exported. Signed-off-by: Sebastian Siewior Tested-by: Stefan Hellermann Signed-off-by: Herbert Xu