1. 12 Jan, 2018 1 commit
    • Eric Biggers's avatar
      crypto: hash - prevent using keyed hashes without setting key · 9fa68f62
      Eric Biggers authored
      Currently, almost none of the keyed hash algorithms check whether a key
      has been set before proceeding.  Some algorithms are okay with this and
      will effectively just use a key of all 0's or some other bogus default.
      However, others will severely break, as demonstrated using
      "hmac(sha3-512-generic)", the unkeyed use of which causes a kernel crash
      via a (potentially exploitable) stack buffer overflow.
      
      A while ago, this problem was solved for AF_ALG by pairing each hash
      transform with a 'has_key' bool.  However, there are still other places
      in the kernel where userspace can specify an arbitrary hash algorithm by
      name, and the kernel uses it as unkeyed hash without checking whether it
      is really unkeyed.  Examples of this include:
      
          - KEYCTL_DH_COMPUTE, via the KDF extension
          - dm-verity
          - dm-crypt, via the ESSIV support
          - dm-integrity, via the "internal hash" mode with no key given
          - drbd (Distributed Replicated Block Device)
      
      This bug is especially bad for KEYCTL_DH_COMPUTE as that requires no
      privileges to call.
      
      Fix the bug for all users by adding a flag CRYPTO_TFM_NEED_KEY to the
      ->crt_flags of each hash transform that indicates whether the transform
      still needs to be keyed or not.  Then, make the hash init, import, and
      digest functions return -ENOKEY if the key is still needed.
      
      The new flag also replaces the 'has_key' bool which algif_hash was
      previously using, thereby simplifying the algif_hash implementation.
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      9fa68f62
  2. 29 Nov, 2017 1 commit
    • Eric Biggers's avatar
      crypto: hmac - require that the underlying hash algorithm is unkeyed · af3ff804
      Eric Biggers authored
      Because the HMAC template didn't check that its underlying hash
      algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))"
      through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC
      being used without having been keyed, resulting in sha3_update() being
      called without sha3_init(), causing a stack buffer overflow.
      
      This is a very old bug, but it seems to have only started causing real
      problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3)
      because the innermost hash's state is ->import()ed from a zeroed buffer,
      and it just so happens that other hash algorithms are fine with that,
      but SHA-3 is not.  However, there could be arch or hardware-dependent
      hash algorithms also affected; I couldn't test everything.
      
      Fix the bug by introducing a function crypto_shash_alg_has_setkey()
      which tests whether a shash algorithm is keyed.  Then update the HMAC
      template to require that its underlying hash algorithm is unkeyed.
      
      Here is a reproducer:
      
          #include <linux/if_alg.h>
          #include <sys/socket.h>
      
          int main()
          {
              int algfd;
              struct sockaddr_alg addr = {
                  .salg_type = "hash",
                  .salg_name = "hmac(hmac(sha3-512-generic))",
              };
              char key[4096] = { 0 };
      
              algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
              bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
              setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
          }
      
      Here was the KASAN report from syzbot:
      
          BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341  [inline]
          BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0  crypto/sha3_generic.c:161
          Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044
      
          CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25
          Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  Google 01/01/2011
          Call Trace:
            __dump_stack lib/dump_stack.c:17 [inline]
            dump_stack+0x194/0x257 lib/dump_stack.c:53
            print_address_description+0x73/0x250 mm/kasan/report.c:252
            kasan_report_error mm/kasan/report.c:351 [inline]
            kasan_report+0x25b/0x340 mm/kasan/report.c:409
            check_memory_region_inline mm/kasan/kasan.c:260 [inline]
            check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
            memcpy+0x37/0x50 mm/kasan/kasan.c:303
            memcpy include/linux/string.h:341 [inline]
            sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
            crypto_shash_update+0xcb/0x220 crypto/shash.c:109
            shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151
            crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
            hmac_finup+0x182/0x330 crypto/hmac.c:152
            crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
            shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172
            crypto_shash_digest+0xc4/0x120 crypto/shash.c:186
            hmac_setkey+0x36a/0x690 crypto/hmac.c:66
            crypto_shash_setkey+0xad/0x190 crypto/shash.c:64
            shash_async_setkey+0x47/0x60 crypto/shash.c:207
            crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200
            hash_setkey+0x40/0x90 crypto/algif_hash.c:446
            alg_setkey crypto/af_alg.c:221 [inline]
            alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254
            SYSC_setsockopt net/socket.c:1851 [inline]
            SyS_setsockopt+0x189/0x360 net/socket.c:1830
            entry_SYSCALL_64_fastpath+0x1f/0x96
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      af3ff804
  3. 10 Oct, 2017 1 commit
  4. 07 Oct, 2017 1 commit
    • Jia-Ju Bai's avatar
      crypto: shash - Fix a sleep-in-atomic bug in shash_setkey_unaligned · 9039f3ef
      Jia-Ju Bai authored
      The SCTP program may sleep under a spinlock, and the function call path is:
      sctp_generate_t3_rtx_event (acquire the spinlock)
        sctp_do_sm
          sctp_side_effects
            sctp_cmd_interpreter
              sctp_make_init_ack
                sctp_pack_cookie
                  crypto_shash_setkey
                    shash_setkey_unaligned
                      kmalloc(GFP_KERNEL)
      
      For the same reason, the orinoco driver may sleep in interrupt handler,
      and the function call path is:
      orinoco_rx_isr_tasklet
        orinoco_rx
          orinoco_mic
            crypto_shash_setkey
              shash_setkey_unaligned
                kmalloc(GFP_KERNEL)
      
      To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
      This bug is found by my static analysis tool and my code review.
      Signed-off-by: 's avatarJia-Ju Bai <baijiaju1990@163.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      9039f3ef
  5. 12 Jan, 2017 1 commit
    • Gideon Israel Dsouza's avatar
      crypto: Replaced gcc specific attributes with macros from compiler.h · d8c34b94
      Gideon Israel Dsouza authored
      Continuing from this commit: 52f5684c
      ("kernel: use macros from compiler.h instead of __attribute__((...))")
      
      I submitted 4 total patches. They are part of task I've taken up to
      increase compiler portability in the kernel. I've cleaned up the
      subsystems under /kernel /mm /block and /security, this patch targets
      /crypto.
      
      There is <linux/compiler.h> which provides macros for various gcc specific
      constructs. Eg: __weak for __attribute__((weak)). I've cleaned all
      instances of gcc specific attributes with the right macros for the crypto
      subsystem.
      
      I had to make one additional change into compiler-gcc.h for the case when
      one wants to use this: __attribute__((aligned) and not specify an alignment
      factor. From the gcc docs, this will result in the largest alignment for
      that data type on the target machine so I've named the macro
      __aligned_largest. Please advise if another name is more appropriate.
      Signed-off-by: 's avatarGideon Israel Dsouza <gidisrael@gmail.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      d8c34b94
  6. 06 Feb, 2016 1 commit
  7. 27 Jan, 2016 1 commit
  8. 18 Jan, 2016 1 commit
  9. 21 Apr, 2015 1 commit
  10. 07 Jun, 2014 1 commit
  11. 19 Feb, 2013 1 commit
    • Mathias Krause's avatar
      crypto: user - fix info leaks in report API · 9a5467bf
      Mathias Krause authored
      Three errors resulting in kernel memory disclosure:
      
      1/ The structures used for the netlink based crypto algorithm report API
      are located on the stack. As snprintf() does not fill the remainder of
      the buffer with null bytes, those stack bytes will be disclosed to users
      of the API. Switch to strncpy() to fix this.
      
      2/ crypto_report_one() does not initialize all field of struct
      crypto_user_alg. Fix this to fix the heap info leak.
      
      3/ For the module name we should copy only as many bytes as
      module_name() returns -- not as much as the destination buffer could
      hold. But the current code does not and therefore copies random data
      from behind the end of the module name, as the module name is always
      shorter than CRYPTO_MAX_ALG_NAME.
      
      Also switch to use strncpy() to copy the algorithm's name and
      driver_name. They are strings, after all.
      Signed-off-by: 's avatarMathias Krause <minipli@googlemail.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      9a5467bf
  12. 01 Aug, 2012 1 commit
  13. 02 Apr, 2012 1 commit
  14. 20 Mar, 2012 1 commit
  15. 10 Nov, 2011 1 commit
  16. 21 Oct, 2011 1 commit
  17. 04 Nov, 2010 1 commit
  18. 19 May, 2010 1 commit
  19. 24 Jul, 2009 1 commit
  20. 22 Jul, 2009 1 commit
    • Herbert Xu's avatar
      crypto: shash - Require all algorithms to support export/import · f592682f
      Herbert Xu authored
      This patch provides a default export/import function for all
      shash algorithms.  It simply copies the descriptor context as
      is done by sha1_generic.
      
      This in essence means that all existing shash algorithms now
      support export/import.  This is something that will be depended
      upon in implementations such as hmac.  Therefore all new shash
      and ahash implementations must support export/import.
      
      For those that cannot obtain a partial result, padlock-sha's
      fallback model should be used so that a partial result is always
      available.
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      f592682f
  21. 15 Jul, 2009 2 commits
  22. 14 Jul, 2009 7 commits
  23. 12 Jul, 2009 1 commit
  24. 11 Jul, 2009 2 commits
  25. 08 Jul, 2009 6 commits
  26. 27 Mar, 2009 1 commit
  27. 18 Feb, 2009 1 commit
    • Herbert Xu's avatar
      crypto: api - Fix crypto_alloc_tfm/create_create_tfm return convention · 3f683d61
      Herbert Xu authored
      This is based on a report and patch by Geert Uytterhoeven.
      
      The functions crypto_alloc_tfm and create_create_tfm return a
      pointer that needs to be adjusted by the caller when successful
      and otherwise an error value.  This means that the caller has
      to check for the error and only perform the adjustment if the
      pointer returned is valid.
      
      Since all callers want to make the adjustment and we know how
      to adjust it ourselves, it's much easier to just return adjusted
      pointer directly.
      
      The only caveat is that we have to return a void * instead of
      struct crypto_tfm *.  However, this isn't that bad because both
      of these functions are for internal use only (by types code like
      shash.c, not even algorithms code).
      
      This patch also moves crypto_alloc_tfm into crypto/internal.h
      (crypto_create_tfm is already there) to reflect this.
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      3f683d61