1. 21 May, 2019 1 commit
    • Eric Biggers's avatar
      crypto: ccm - fix incompatibility between "ccm" and "ccm_base" · 654a509d
      Eric Biggers authored
      commit 6a1faa4a upstream.
      CCM instances can be created by either the "ccm" template, which only
      allows choosing the block cipher, e.g. "ccm(aes)"; or by "ccm_base",
      which allows choosing the ctr and cbcmac implementations, e.g.
      However, a "ccm_base" instance prevents a "ccm" instance from being
      registered using the same implementations.  Nor will the instance be
      found by lookups of "ccm".  This can be used as a denial of service.
      Moreover, "ccm_base" instances are never tested by the crypto
      self-tests, even if there are compatible "ccm" tests.
      The root cause of these problems is that instances of the two templates
      use different cra_names.  Therefore, fix these problems by making
      "ccm_base" instances set the same cra_name as "ccm" instances, e.g.
      "ccm(aes)" instead of "ccm_base(ctr(aes-generic),cbcmac(aes-generic))".
      This requires extracting the block cipher name from the name of the ctr
      and cbcmac algorithms.  It also requires starting to verify that the
      algorithms are really ctr and cbcmac using the same block cipher, not
      something else entirely.  But it would be bizarre if anyone were
      actually using non-ccm-compatible algorithms with ccm_base, so this
      shouldn't break anyone in practice.
      Fixes: 4a49b499 ("[CRYPTO] ccm: Added CCM mode")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 03 Nov, 2017 1 commit
    • Romain Izard's avatar
      crypto: ccm - preserve the IV buffer · 441f99c9
      Romain Izard authored
      The IV buffer used during CCM operations is used twice, during both the
      hashing step and the ciphering step.
      When using a hardware accelerator that updates the contents of the IV
      buffer at the end of ciphering operations, the value will be modified.
      In the decryption case, the subsequent setup of the hashing algorithm
      will interpret the updated IV instead of the original value, which can
      lead to out-of-bounds writes.
      Reuse the idata buffer, only used in the hashing step, to preserve the
      IV's value during the ciphering step in the decryption case.
      Signed-off-by: default avatarRomain Izard <romain.izard.pro@gmail.com>
      Reviewed-by: default avatarTudor Ambarus <tudor.ambarus@microchip.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  3. 28 Feb, 2017 1 commit
  4. 15 Feb, 2017 2 commits
  5. 11 Feb, 2017 1 commit
    • Ard Biesheuvel's avatar
      crypto: ccm - switch to separate cbcmac driver · f15f05b0
      Ard Biesheuvel authored
      Update the generic CCM driver to defer CBC-MAC processing to a
      dedicated CBC-MAC ahash transform rather than open coding this
      transform (and much of the associated scatterwalk plumbing) in
      the CCM driver itself.
      This cleans up the code considerably, but more importantly, it allows
      the use of alternative CBC-MAC implementations that don't suffer from
      performance degradation due to significant setup time (e.g., the NEON
      based AES code needs to enable/disable the NEON, and load the S-box
      into 16 SIMD registers, which cannot be amortized over the entire input
      when using the cipher interface)
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  6. 01 Nov, 2016 2 commits
  7. 18 Jul, 2016 1 commit
  8. 17 Aug, 2015 2 commits
  9. 17 Jul, 2015 1 commit
  10. 13 May, 2015 1 commit
  11. 26 Nov, 2014 1 commit
  12. 24 Nov, 2014 1 commit
  13. 28 Nov, 2013 1 commit
    • Horia Geanta's avatar
      crypto: ccm - Fix handling of zero plaintext when computing mac · 5638cabf
      Horia Geanta authored
      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: <stable@vger.kernel.org>
      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>
  14. 07 Oct, 2013 1 commit
    • James Yonan's avatar
      crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks · 6bf37e5a
      James Yonan authored
      When comparing MAC hashes, AEAD authentication tags, or other hash
      values in the context of authentication or integrity checking, it
      is important not to leak timing information to a potential attacker,
      i.e. when communication happens over a network.
      Bytewise memory comparisons (such as memcmp) are usually optimized so
      that they return a nonzero value as soon as a mismatch is found. E.g,
      on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
      and up to ~850 cyc for a full match (cold). This early-return behavior
      can leak timing information as a side channel, allowing an attacker to
      iteratively guess the correct result.
      This patch adds a new method crypto_memneq ("memory not equal to each
      other") to the crypto API that compares memory areas of the same length
      in roughly "constant time" (cache misses could change the timing, but
      since they don't reveal information about the content of the strings
      being compared, they are effectively benign). Iow, best and worst case
      behaviour take the same amount of time to complete (in contrast to
      Note that crypto_memneq (unlike memcmp) can only be used to test for
      equality or inequality, NOT for lexicographical order. This, however,
      is not an issue for its use-cases within the crypto API.
      We tried to locate all of the places in the crypto API where memcmp was
      being used for authentication or integrity checking, and convert them
      over to crypto_memneq.
      crypto_memneq is declared noinline, placed in its own source file,
      and compiled with optimizations that might increase code size disabled
      ("Os") because a smart compiler (or LTO) might notice that the return
      value is always compared against zero/nonzero, and might then
      reintroduce the same early-return optimization that we are trying to
      Using #pragma or __attribute__ optimization annotations of the code
      for disabling optimization was avoided as it seems to be considered
      broken or unmaintained for long time in GCC [1]. Therefore, we work
      around that by specifying the compile flag for memneq.o directly in
      the Makefile. We found that this seems to be most appropriate.
      As we use ("Os"), this patch also provides a loop-free "fast-path" for
      frequently used 16 byte digests. Similarly to kernel library string
      functions, leave an option for future even further optimized architecture
      specific assembler implementations.
      This was a joint work of James Yonan and Daniel Borkmann. Also thanks
      for feedback from Florian Weimer on this and earlier proposals [2].
        [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
        [2] https://lkml.org/lkml/2013/2/10/131Signed-off-by: default avatarJames Yonan <james@openvpn.net>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Florian Weimer <fw@deneb.enyo.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  15. 04 Feb, 2013 1 commit
  16. 20 Mar, 2012 1 commit
  17. 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>
  18. 10 Jan, 2008 1 commit