From 29b37f42127f7da511560a40ea74f5047da40c13 Mon Sep 17 00:00:00 2001 From: Herbert Xu Date: Tue, 13 Jan 2009 11:26:18 +1100 Subject: crypto: authenc - Fix zero-length IV crash As it is if an algorithm with a zero-length IV is used (e.g., NULL encryption) with authenc, authenc may generate an SG entry of length zero, which will trigger a BUG check in the hash layer. This patch fixes it by skipping the IV SG generation if the IV size is zero. Signed-off-by: Herbert Xu --- crypto/authenc.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) (limited to 'crypto') diff --git a/crypto/authenc.c b/crypto/authenc.c index 40b6e9ec9e3..5793b64c81a 100644 --- a/crypto/authenc.c +++ b/crypto/authenc.c @@ -158,16 +158,19 @@ static int crypto_authenc_genicv(struct aead_request *req, u8 *iv, dstp = sg_page(dst); vdst = PageHighMem(dstp) ? NULL : page_address(dstp) + dst->offset; - sg_init_table(cipher, 2); - sg_set_buf(cipher, iv, ivsize); - authenc_chain(cipher, dst, vdst == iv + ivsize); + if (ivsize) { + sg_init_table(cipher, 2); + sg_set_buf(cipher, iv, ivsize); + authenc_chain(cipher, dst, vdst == iv + ivsize); + dst = cipher; + } cryptlen = req->cryptlen + ivsize; - hash = crypto_authenc_hash(req, flags, cipher, cryptlen); + hash = crypto_authenc_hash(req, flags, dst, cryptlen); if (IS_ERR(hash)) return PTR_ERR(hash); - scatterwalk_map_and_copy(hash, cipher, cryptlen, + scatterwalk_map_and_copy(hash, dst, cryptlen, crypto_aead_authsize(authenc), 1); return 0; } @@ -285,11 +288,14 @@ static int crypto_authenc_iverify(struct aead_request *req, u8 *iv, srcp = sg_page(src); vsrc = PageHighMem(srcp) ? NULL : page_address(srcp) + src->offset; - sg_init_table(cipher, 2); - sg_set_buf(cipher, iv, ivsize); - authenc_chain(cipher, src, vsrc == iv + ivsize); + if (ivsize) { + sg_init_table(cipher, 2); + sg_set_buf(cipher, iv, ivsize); + authenc_chain(cipher, src, vsrc == iv + ivsize); + src = cipher; + } - return crypto_authenc_verify(req, cipher, cryptlen + ivsize); + return crypto_authenc_verify(req, src, cryptlen + ivsize); } static int crypto_authenc_decrypt(struct aead_request *req) -- cgit v1.2.3 From bac1b5c4696f217afeac5b29874a337bc39da717 Mon Sep 17 00:00:00 2001 From: Herbert Xu Date: Fri, 16 Jan 2009 14:40:54 +1100 Subject: crypto: blkcipher - Fix WARN_ON handling in walk_done When we get left-over bits from a slow walk, it means that the underlying cipher has gone troppo. However, as we're handling that case we should ensure that the caller terminates the walk. This patch does this by setting walk->nbytes to zero. Reported-by: Roel Kluin Reported-by: Huang Ying Signed-off-by: Herbert Xu --- crypto/blkcipher.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'crypto') diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c index 4a7e65c4df4..d70a41c002d 100644 --- a/crypto/blkcipher.c +++ b/crypto/blkcipher.c @@ -124,6 +124,7 @@ int blkcipher_walk_done(struct blkcipher_desc *desc, scatterwalk_done(&walk->in, 0, nbytes); scatterwalk_done(&walk->out, 1, nbytes); +err: walk->total = nbytes; walk->nbytes = nbytes; @@ -132,7 +133,6 @@ int blkcipher_walk_done(struct blkcipher_desc *desc, return blkcipher_walk_next(desc, walk); } -err: if (walk->iv != desc->info) memcpy(desc->info, walk->iv, crypto_blkcipher_ivsize(tfm)); if (walk->buffer != walk->page) -- cgit v1.2.3 From 516280e735b034216de97eb7ba080ec6acbfc58f Mon Sep 17 00:00:00 2001 From: Jarod Wilson Date: Thu, 22 Jan 2009 19:58:15 +1100 Subject: crypto: ccm - Fix handling of null assoc data Its a valid use case to have null associated data in a ccm vector, but this case isn't being handled properly right now. The following ccm decryption/verification test vector, using the rfc4309 implementation regularly triggers a panic, as will any other vector with null assoc data: * key: ab2f8a74b71cd2b1ff802e487d82f8b9 * iv: c6fb7d800d13abd8a6b2d8 * Associated Data: [NULL] * Tag Length: 8 * input: d5e8939fc7892e2b The resulting panic looks like so: Unable to handle kernel paging request at ffff810064ddaec0 RIP: [] :ccm:get_data_to_compute+0x1a6/0x1d6 PGD 8063 PUD 0 Oops: 0002 [1] SMP last sysfs file: /module/libata/version CPU 0 Modules linked in: crypto_tester_kmod(U) seqiv krng ansi_cprng chainiv rng ctr aes_generic aes_x86_64 ccm cryptomgr testmgr_cipher testmgr aead crypto_blkcipher crypto_a lgapi des ipv6 xfrm_nalgo crypto_api autofs4 hidp l2cap bluetooth nfs lockd fscache nfs_acl sunrpc ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_ tcpudp iptable_filter ip_tables x_tables dm_mirror dm_log dm_multipath scsi_dh dm_mod video hwmon backlight sbs i2c_ec button battery asus_acpi acpi_memhotplug ac lp sg snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss joydev snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ide_cd snd_pcm floppy parport_p c shpchp e752x_edac snd_timer e1000 i2c_i801 edac_mc snd soundcore snd_page_alloc i2c_core cdrom parport serio_raw pcspkr ata_piix libata sd_mod scsi_mod ext3 jbd uhci_h cd ohci_hcd ehci_hcd Pid: 12844, comm: crypto-tester Tainted: G 2.6.18-128.el5.fips1 #1 RIP: 0010:[] [] :ccm:get_data_to_compute+0x1a6/0x1d6 RSP: 0018:ffff8100134434e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8100104898b0 RCX: ffffffffab6aea10 RDX: 0000000000000010 RSI: ffff8100104898c0 RDI: ffff810064ddaec0 RBP: 0000000000000000 R08: ffff8100104898b0 R09: 0000000000000000 R10: ffff8100103bac84 R11: ffff8100104898b0 R12: ffff810010489858 R13: ffff8100104898b0 R14: ffff8100103bac00 R15: 0000000000000000 FS: 00002ab881adfd30(0000) GS:ffffffff803ac000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff810064ddaec0 CR3: 0000000012a88000 CR4: 00000000000006e0 Process crypto-tester (pid: 12844, threadinfo ffff810013442000, task ffff81003d165860) Stack: ffff8100103bac00 ffff8100104898e8 ffff8100134436f8 ffffffff00000000 0000000000000000 ffff8100104898b0 0000000000000000 ffff810010489858 0000000000000000 ffff8100103bac00 ffff8100134436f8 ffffffff8864c634 Call Trace: [] :ccm:crypto_ccm_auth+0x12d/0x140 [] :ccm:crypto_ccm_decrypt+0x161/0x23a [] :crypto_tester_kmod:cavs_test_rfc4309_ccm+0x4a5/0x559 [...] The above is from a RHEL5-based kernel, but upstream is susceptible too. The fix is trivial: in crypto/ccm.c:crypto_ccm_auth(), pctx->ilen contains whatever was in memory when pctx was allocated if assoclen is 0. The tested fix is to simply add an else clause setting pctx->ilen to 0 for the assoclen == 0 case, so that get_data_to_compute() doesn't try doing things its not supposed to. Signed-off-by: Jarod Wilson Acked-by: Neil Horman Signed-off-by: Herbert Xu --- crypto/ccm.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'crypto') diff --git a/crypto/ccm.c b/crypto/ccm.c index 7cf7e5a6b78..c36d654cf56 100644 --- a/crypto/ccm.c +++ b/crypto/ccm.c @@ -266,6 +266,8 @@ static int crypto_ccm_auth(struct aead_request *req, struct scatterlist *plain, if (assoclen) { pctx->ilen = format_adata(idata, assoclen); get_data_to_compute(cipher, pctx, req->assoc, req->assoclen); + } else { + pctx->ilen = 0; } /* compute plaintext into mac */ -- cgit v1.2.3