1. 24 3月, 2019 1 次提交
    • E
      crypto: aead - set CRYPTO_TFM_NEED_KEY if ->setkey() fails · 736807d6
      Eric Biggers 提交于
      commit 6ebc97006b196aafa9df0497fdfa866cf26f259b upstream.
      
      Some algorithms have a ->setkey() method that is not atomic, in the
      sense that setting a key can fail after changes were already made to the
      tfm context.  In this case, if a key was already set the tfm can end up
      in a state that corresponds to neither the old key nor the new key.
      
      For example, in gcm.c, if the kzalloc() fails due to lack of memory,
      then the CTR part of GCM will have the new key but GHASH will not.
      
      It's not feasible to make all ->setkey() methods atomic, especially ones
      that have to key multiple sub-tfms.  Therefore, make the crypto API set
      CRYPTO_TFM_NEED_KEY if ->setkey() fails, to prevent the tfm from being
      used until a new key is set.
      
      [Cc stable mainly because when introducing the NEED_KEY flag I changed
       AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG
       previously didn't have this problem.  So these "incompletely keyed"
       states became theoretically accessible via AF_ALG -- though, the
       opportunities for causing real mischief seem pretty limited.]
      
      Fixes: dc26c17f ("crypto: aead - prevent using AEADs without setting key")
      Cc: <stable@vger.kernel.org> # v4.16+
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      736807d6
  2. 12 1月, 2018 1 次提交
    • E
      crypto: aead - prevent using AEADs without setting key · dc26c17f
      Eric Biggers 提交于
      Similar to what was done for the hash API, update the AEAD API to track
      whether each transform has been keyed, and reject encryption/decryption
      if a key is needed but one hasn't been set.
      
      This isn't quite as important as the equivalent fix for the hash API
      because AEADs always require a key, so are unlikely to be used without
      one.  Still, tracking the key will prevent accidental unkeyed use.
      algif_aead also had to track the key anyway, so the new flag replaces
      that and slightly simplifies the algif_aead implementation.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      dc26c17f
  3. 22 12月, 2017 1 次提交
  4. 13 1月, 2017 1 次提交
    • G
      crypto: Replaced gcc specific attributes with macros from compiler.h · d8c34b94
      Gideon Israel Dsouza 提交于
      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: NGideon Israel Dsouza <gidisrael@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      d8c34b94
  5. 18 7月, 2016 3 次提交
  6. 17 8月, 2015 3 次提交
  7. 14 7月, 2015 2 次提交
  8. 03 6月, 2015 3 次提交
  9. 28 5月, 2015 2 次提交
  10. 25 5月, 2015 4 次提交
  11. 22 5月, 2015 4 次提交
    • H
      crypto: seqiv - Add support for new AEAD interface · 856e3f40
      Herbert Xu 提交于
      This patch converts the seqiv IV generator to work with the new
      AEAD interface where IV generators are just normal AEAD algorithms.
      
      Full backwards compatibility is paramount at this point since
      no users have yet switched over to the new interface.  Nor can
      they switch to the new interface until IV generation is fully
      supported by it.
      
      So this means we are adding two versions of seqiv alongside the
      existing one.  The first one is the one that will be used when
      the underlying AEAD algorithm has switched over to the new AEAD
      interface.  The second one handles the current case where the
      underlying AEAD algorithm still uses the old interface.
      
      Both versions export themselves through the new AEAD interface.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      856e3f40
    • H
      crypto: aead - Add support for new AEAD implementations · 63293c61
      Herbert Xu 提交于
      This patch adds the basic structure of the new AEAD type.  Unlike
      the current version, there is no longer any concept of geniv.  IV
      generation will still be carried out by wrappers but they will be
      normal AEAD algorithms that simply take the IPsec sequence number
      as the IV.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      63293c61
    • H
      crypto: aead - Rename aead_alg to old_aead_alg · 2d0f230f
      Herbert Xu 提交于
      This patch is the first step in the introduction of a new AEAD
      alg type.  Unlike normal conversions this patch only renames the
      existing aead_alg structure because there are external references
      to it.
      
      Those references will be removed after this patch.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2d0f230f
    • H
      crypto: aead - Add new interface with single SG list · 996d98d8
      Herbert Xu 提交于
      The primary user of AEAD, IPsec includes the IV in the AD in
      most cases, except where it is implicitly authenticated by the
      underlying algorithm.
      
      The way it is currently implemented is a hack because we pass
      the data in piecemeal and the underlying algorithms try to stitch
      them back up into one piece.
      
      This is why this patch is adding a new interface that allows a
      single SG list to be passed in that contains everything so the
      algorithm implementors do not have to stitch.
      
      The new interface accepts a single source SG list and a single
      destination SG list.  Both must be laid out as follows:
      
      	AD, skipped data, plain/cipher text, ICV
      
      The ICV is not present from the source during encryption and from
      the destination during decryption.
      
      For the top-level IPsec AEAD algorithm the plain/cipher text will
      contain the generated (or received) IV.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      996d98d8
  12. 13 5月, 2015 1 次提交
    • H
      crypto: aead - Convert top level interface to new style · 5d1d65f8
      Herbert Xu 提交于
      This patch converts the top-level aead interface to the new style.
      All user-level AEAD interface code have been moved into crypto/aead.h.
      
      The allocation/free functions have switched over to the new way of
      allocating tfms.
      
      This patch also removes the double indrection on setkey so the
      indirection now exists only at the alg level.
      
      Apart from these there are no user-visible changes.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5d1d65f8
  13. 26 4月, 2015 1 次提交
  14. 22 12月, 2014 1 次提交
  15. 19 2月, 2013 1 次提交
    • M
      crypto: user - fix info leaks in report API · 9a5467bf
      Mathias Krause 提交于
      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: NMathias Krause <minipli@googlemail.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      9a5467bf
  16. 04 2月, 2013 1 次提交
  17. 02 4月, 2012 1 次提交
  18. 29 3月, 2012 1 次提交
  19. 11 11月, 2011 1 次提交
  20. 21 10月, 2011 2 次提交
  21. 16 2月, 2010 1 次提交
  22. 12 10月, 2009 1 次提交
  23. 18 2月, 2009 1 次提交
    • H
      crypto: aead - Avoid infinite loop when nivaead fails selftest · 5852ae42
      Herbert Xu 提交于
      When an aead constructed through crypto_nivaead_default fails
      its selftest, we'll loop forever trying to construct new aead
      objects but failing because it already exists.
      
      The crux of the issue is that once an aead fails the selftest,
      we'll ignore it on the next run through crypto_aead_lookup and
      attempt to construct a new aead.
      
      We should instead return an error to the caller if we find an
      an that has failed the test.
      
      This bug hasn't manifested itself yet because we don't have any
      test vectors for the existing nivaead algorithms.  They're tested
      through the underlying algorithms only.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5852ae42
  24. 11 1月, 2008 2 次提交