Bug 481031

Summary: crypto: panic handling ccm vectors with null associated data
Product: Red Hat Enterprise Linux 5 Reporter: Jarod Wilson <jarod>
Component: kernelAssignee: Jarod Wilson <jarod>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: low    
Version: 5.4CC: emcnabb, herbert.xu, lwang, nhorman
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 08:59:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 444768    
Attachments:
Description Flags
Fix to make null assoc data vectors work properly none

Description Jarod Wilson 2009-01-21 20:37:01 UTC 
Description of problem:
CCM-mode crypto operations (specifically, rfc4309(ccm(aes))) executed with null associated data result in a kernel panic most of the time.

----8<----
crypto_tester: 
 * cipher: rfc4309(ccm(aes))
 * key: ab2f8a74b71cd2b1ff802e487d82f8b9
 * iv: c6fb7d800d13abd8a6b2d8
 * Associated Data: [NULL]
 * Tag Length: 8
 * input: d5e8939fc7892e2b
 * encdec: 0, klen: 16, ivlen: 11 ilen: 8
Unable to handle kernel paging request at ffff810064ddaec0 RIP: 
 [<ffffffff8864c4d7>] :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:[<ffffffff8864c4d7>]  [<ffffffff8864c4d7>] :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:
 [<ffffffff8864c634>] :ccm:crypto_ccm_auth+0x12d/0x140
 [<ffffffff8864cf73>] :ccm:crypto_ccm_decrypt+0x161/0x23a
 [<ffffffff88633643>] :crypto_tester_kmod:cavs_test_rfc4309_ccm+0x4a5/0x559
 [<ffffffff801b3cdf>] serial8250_console_putchar+0x3f/0xa6
 [<ffffffff8009db2a>] autoremove_wake_function+0x9/0x2e
 [<ffffffff80063097>] thread_return+0x62/0xfe
 [<ffffffff886346f6>] :crypto_tester_kmod:cavs_user_cmd+0x8c8/0x116a
[...]
----8<----

The fix for the problem is trivial though. In crypto/ccm.c's crypto_ccm_auth() function, pctx is allocated from memory, but not zeroed out or anything. If assoclen == 0, pctx->ilen never gets set to anything, so its whatever random garbage was in that portion of memory. Things behave correctly if we simply make sure to set pctx->ilen to 0 when assoclen == 0. Patch coming shortly, will submit upstream in a moment as well.
Comment 1 Jarod Wilson 2009-01-21 20:59:10 UTC 
Created attachment 329652 [details]
Fix to make null assoc data vectors work properly
Comment 2 Jarod Wilson 2009-01-21 21:40:46 UTC 
Patch submitted upstream:

http://lkml.org/lkml/2009/1/21/306
Comment 3 Jarod Wilson 2009-01-30 18:14:46 UTC 
Patch is in the upstream crypto tree now:

http://git.kernel.org/?p=linux/kernel/git/herbert/crypto-2.6.git;a=commitdiff;h=516280e735b034216de97eb7ba080ec6acbfc58f
Comment 5 RHEL Program Management 2009-02-03 03:38:48 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 6 Don Zickus 2009-02-09 18:26:04 UTC 
in kernel-2.6.18-131.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 7 RHEL Program Management 2009-02-16 15:44:20 UTC 
Updating PM score.
Comment 12 errata-xmlrpc 2009-09-02 08:59:25 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html