1. 15 May, 2015 2 commits
  2. 30 Jan, 2015 2 commits
  3. 12 Dec, 2013 1 commit
    • Horia Geanta's avatar
      crypto: ccm - Fix handling of zero plaintext when computing mac · bf2e5230
      Horia Geanta authored
      commit 5638cabf3e4883f38dfb246c30980cebf694fbda upstream.
      
      There are cases when cryptlen can be zero in crypto_ccm_auth():
      -encryptiom: input scatterlist length is zero (no plaintext)
      -decryption: input scatterlist contains only the mac
      plus the condition of having different source and destination buffers
      (or else scatterlist length = max(plaintext_len, ciphertext_len)).
      
      These are not handled correctly, leading to crashes like:
      
      root@p4080ds:~/crypto# insmod tcrypt.ko mode=45
      ------------[ cut here ]------------
      kernel BUG at crypto/scatterwalk.c:37!
      Oops: Exception in kernel mode, sig: 5 [#1]
      SMP NR_CPUS=8 P4080 DS
      Modules linked in: tcrypt(+) crc32c xts xcbc vmac pcbc ecb gcm ghash_generic gf128mul ccm ctr seqiv
      CPU: 3 PID: 1082 Comm: cryptomgr_test Not tainted 3.11.0 #14
      task: ee12c5b0 ti: eecd0000 task.ti: eecd0000
      NIP: c0204d98 LR: f9225848 CTR: c0204d80
      REGS: eecd1b70 TRAP: 0700   Not tainted  (3.11.0)
      MSR: 00029002 <CE,EE,ME>  CR: 22044022  XER: 20000000
      
      GPR00: f9225c94 eecd1c20 ee12c5b0 eecd1c28 ee879400 ee879400 00000000 ee607464
      GPR08: 00000001 00000001 00000000 006b0000 c0204d80 00000000 00000002 c0698e20
      GPR16: ee987000 ee895000 fffffff4 ee879500 00000100 eecd1d58 00000001 00000000
      GPR24: ee879400 00000020 00000000 00000000 ee5b2800 ee607430 00000004 ee607460
      NIP [c0204d98] scatterwalk_start+0x18/0x30
      LR [f9225848] get_data_to_compute+0x28/0x2f0 [ccm]
      Call Trace:
      [eecd1c20] [f9225974] get_data_to_compute+0x154/0x2f0 [ccm] (unreliable)
      [eecd1c70] [f9225c94] crypto_ccm_auth+0x184/0x1d0 [ccm]
      [eecd1cb0] [f9225d40] crypto_ccm_encrypt+0x60/0x2d0 [ccm]
      [eecd1cf0] [c020d77c] __test_aead+0x3ec/0xe20
      [eecd1e20] [c020f35c] test_aead+0x6c/0xe0
      [eecd1e40] [c020f420] alg_test_aead+0x50/0xd0
      [eecd1e60] [c020e5e4] alg_test+0x114/0x2e0
      [eecd1ee0] [c020bd1c] cryptomgr_test+0x4c/0x60
      [eecd1ef0] [c0047058] kthread+0xa8/0xb0
      [eecd1f40] [c000eb0c] ret_from_kernel_thread+0x5c/0x64
      Instruction dump:
      0f080000 81290024 552807fe 0f080000 5529003a 4bffffb4 90830000 39400000
      39000001 8124000c 2f890000 7d28579e <0f090000> 81240008 91230004 4e800020
      ---[ end trace 6d652dfcd1be37bd ]---
      
      Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: default avatarHoria Geanta <horia.geanta@freescale.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf2e5230
  4. 04 Feb, 2013 1 commit
  5. 20 Mar, 2012 1 commit
  6. 27 Jan, 2009 1 commit
    • Jarod Wilson's avatar
      crypto: ccm - Fix handling of null assoc data · 516280e7
      Jarod Wilson authored
      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: 
       [<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
      [...]
      
      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: default avatarJarod Wilson <jarod@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      516280e7
  7. 10 Jan, 2008 1 commit