linux/crypto, branch v2.6.25.13

crypto: chainiv - Invoke completion function

2008-07-24T16:14:10Z

Upstream commit: 872ac8743cb400192a9fce4ba2d3ffd7bb309685 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 Signed-off-by: Greg Kroah-Hartman

CRYPTO: eseqiv: Fix off-by-one encryption

2008-05-10T04:40:52Z

[CRYPTO] eseqiv: Fix off-by-one encryption [ Upstream commit: 46f8153cc59384eb09a426d044668d4801f818ce ] 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 Signed-off-by: Greg Kroah-Hartman

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

2008-05-10T04:40:52Z

[CRYPTO] authenc: Fix async crypto crash in crypto_authenc_genicv() [ Upstream commit: 161613293fd4b7d5ceb1faab788f47e688e07a67 ] 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 Signed-off-by: Greg Kroah-Hartman

CRYPTO: cryptd: Correct kzalloc error test

2008-05-10T04:40:51Z

[CRYPTO] cryptd: Correct kzalloc error test [ Upstream commit: b1145ce395f7785487c128fe8faf8624e6586d84 ] 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 Signed-off-by: Greg Kroah-Hartman

[CRYPTO] xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk

2008-04-02T06:36:09Z

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: Joy Latten Signed-off-by: Herbert Xu

async_tx: avoid the async xor_zero_sum path when src_cnt > device->max_xor

2008-03-19T00:01:00Z

If the channel cannot perform the operation in one call to ->device_prep_dma_zero_sum, then fallback to the xor+page_is_zero path. This only affects users with arrays larger than 16 devices on iop13xx or 32 devices on iop3xx. Cc: Cc: Neil Brown Signed-off-by: Dan Williams

async_tx: checkpatch says s/FUNCTION/func/g

2008-03-13T17:57:10Z

Signed-off-by: Dan Williams

[CRYPTO] skcipher: Fix section mismatches

2008-03-08T12:29:43Z

The previous patch to move chainiv and eseqiv into blkcipher created a section mismatch for the chainiv exit function which was also called from __init. This patch removes the __exit marking on it. Signed-off-by: Herbert Xu

[CRYPTO] xcbc: Fix crash with IPsec

2008-03-06T11:28:44Z

When using aes-xcbc-mac for authentication in IPsec, the kernel crashes. It seems this algorithm doesn't account for the space IPsec may make in scatterlist for authtag. Thus when crypto_xcbc_digest_update2() gets called, nbytes may be less than sg[i].length. Since nbytes is an unsigned number, it wraps at the end of the loop allowing us to go back into loop and causing crash in memcpy. I used update function in digest.c to model this fix. Please let me know if it looks ok. Signed-off-by: Joy Latten Signed-off-by: Herbert Xu

[CRYPTO] xts: Use proper alignment

2008-03-06T10:56:19Z

The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by: Sebastian Siewior Tested-by: Stefan Hellermann Signed-off-by: Herbert Xu