Bug 481031 - crypto: panic handling ccm vectors with null associated data
crypto: panic handling ccm vectors with null associated data
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Jarod Wilson
Red Hat Kernel QE team
Depends On:
Blocks: FIPS-140-Tracker
  Show dependency treegraph
Reported: 2009-01-21 15:37 EST by Jarod Wilson
Modified: 2009-09-02 04:59 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 04:59:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix to make null assoc data vectors work properly (485 bytes, patch)
2009-01-21 15:59 EST, Jarod Wilson
no flags Details | Diff

  None (edit)
Description Jarod Wilson 2009-01-21 15:37:01 EST
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.

 * 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

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 15:59:10 EST
Created attachment 329652 [details]
Fix to make null assoc data vectors work properly
Comment 2 Jarod Wilson 2009-01-21 16:40:46 EST
Patch submitted upstream:

Comment 5 RHEL Product and Program Management 2009-02-02 22:38:48 EST
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
Comment 6 Don Zickus 2009-02-09 13:26:04 EST
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 Product and Program Management 2009-02-16 10:44:20 EST
Updating PM score.
Comment 12 errata-xmlrpc 2009-09-02 04:59:25 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.