1. 16 7月, 2020 1 次提交
    • E
      crypto: algapi - use common mechanism for inheriting flags · 7bcb2c99
      Eric Biggers 提交于
      The flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when a
      template is instantiated, the template will have CRYPTO_ALG_ASYNC set if
      any of the algorithms it uses has CRYPTO_ALG_ASYNC set.
      
      We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that gets
      "inherited" in the same way.  This is difficult because the handling of
      CRYPTO_ALG_ASYNC is hardcoded everywhere.  Address this by:
      
        - Add CRYPTO_ALG_INHERITED_FLAGS, which contains the set of flags that
          have these inheritance semantics.
      
        - Add crypto_algt_inherited_mask(), for use by template ->create()
          methods.  It returns any of these flags that the user asked to be
          unset and thus must be passed in the 'mask' to crypto_grab_*().
      
        - Also modify crypto_check_attr_type() to handle computing the 'mask'
          so that most templates can just use this.
      
        - Make crypto_grab_*() propagate these flags to the template instance
          being created so that templates don't have to do this themselves.
      
      Make crypto/simd.c propagate these flags too, since it "wraps" another
      algorithm, similar to a template.
      
      Based on a patch by Mikulas Patocka <mpatocka@redhat.com>
      (https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com).
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7bcb2c99
  2. 08 5月, 2020 1 次提交
  3. 16 4月, 2020 2 次提交
    • H
      crypto: api - Fix use-after-free and race in crypto_spawn_alg · 6603523b
      Herbert Xu 提交于
      There are two problems in crypto_spawn_alg.  First of all it may
      return spawn->alg even if spawn->dead is set.  This results in a
      double-free as detected by syzbot.
      
      Secondly the setting of the DYING flag is racy because we hold
      the read-lock instead of the write-lock.  We should instead call
      crypto_shoot_alg in a safe manner by gaining a refcount, dropping
      the lock, and then releasing the refcount.
      
      This patch fixes both problems.
      
      Reported-by: syzbot+fc0674cde00b66844470@syzkaller.appspotmail.com
      Fixes: 4f87ee11 ("crypto: api - Do not zap spawn->alg")
      Fixes: 73669cc5 ("crypto: api - Fix race condition in...")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6603523b
    • E
      crypto: algapi - Avoid spurious modprobe on LOADED · beeb460c
      Eric Biggers 提交于
      Currently after any algorithm is registered and tested, there's an
      unnecessary request_module("cryptomgr") even if it's already loaded.
      Also, CRYPTO_MSG_ALG_LOADED is sent twice, and thus if the algorithm is
      "crct10dif", lib/crc-t10dif.c replaces the tfm twice rather than once.
      
      This occurs because CRYPTO_MSG_ALG_LOADED is sent using
      crypto_probing_notify(), which tries to load "cryptomgr" if the
      notification is not handled (NOTIFY_DONE).  This doesn't make sense
      because "cryptomgr" doesn't handle this notification.
      
      Fix this by using crypto_notify() instead of crypto_probing_notify().
      
      Fixes: dd8b083f ("crypto: api - Introduce notifier for new crypto algorithms")
      Cc: <stable@vger.kernel.org> # v4.20+
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      beeb460c
  4. 09 1月, 2020 6 次提交
  5. 27 12月, 2019 1 次提交
    • H
      crypto: api - Retain alg refcount in crypto_grab_spawn · 5f567fff
      Herbert Xu 提交于
      This patch changes crypto_grab_spawn to retain the reference count
      on the algorithm.  This is because the caller needs to access the
      algorithm parameters and without the reference count the algorithm
      can be freed at any time.
      
      The reference count will be subsequently dropped by the crypto API
      once the instance has been registered.  The helper crypto_drop_spawn
      will also conditionally drop the reference count depending on whether
      it has been registered.
      
      Note that the code is actually added to crypto_init_spawn.  However,
      unless the caller activates this by setting spawn->dropref beforehand
      then nothing happens.  The only caller that sets dropref is currently
      crypto_grab_spawn.
      
      Once all legacy users of crypto_init_spawn disappear, then we can
      kill the dropref flag.
      
      Internally each instance will maintain a list of its spawns prior
      to registration.  This memory used by this list is shared with
      other fields that are only used after registration.  In order for
      this to work a new flag spawn->registered is added to indicate
      whether spawn->inst can be used.
      
      Fixes: d6ef2f19 ("crypto: api - Add crypto_grab_spawn primitive")
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5f567fff
  6. 20 12月, 2019 2 次提交
    • E
      crypto: algapi - make unregistration functions return void · c6d633a9
      Eric Biggers 提交于
      Some of the algorithm unregistration functions return -ENOENT when asked
      to unregister a non-registered algorithm, while others always return 0
      or always return void.  But no users check the return value, except for
      two of the bulk unregistration functions which print a message on error
      but still always return 0 to their caller, and crypto_del_alg() which
      calls crypto_unregister_instance() which always returns 0.
      
      Since unregistering a non-registered algorithm is always a kernel bug
      but there isn't anything callers should do to handle this situation at
      runtime, let's simplify things by making all the unregistration
      functions return void, and moving the error message into
      crypto_unregister_alg() and upgrading it to a WARN().
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c6d633a9
    • H
      crypto: api - fix unexpectedly getting generic implementation · 2bbb3375
      Herbert Xu 提交于
      When CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, the first lookup of an
      algorithm that needs to be instantiated using a template will always get
      the generic implementation, even when an accelerated one is available.
      
      This happens because the extra self-tests for the accelerated
      implementation allocate the generic implementation for comparison
      purposes, and then crypto_alg_tested() for the generic implementation
      "fulfills" the original request (i.e. sets crypto_larval::adult).
      
      This patch fixes this by only fulfilling the original request if
      we are currently the best outstanding larval as judged by the
      priority.  If we're not the best then we will ask all waiters on
      that larval request to retry the lookup.
      
      Note that this patch introduces a behaviour change when the module
      providing the new algorithm is unregistered during the process.
      Previously we would have failed with ENOENT, after the patch we
      will instead redo the lookup.
      
      Fixes: 9a8a6b3f ("crypto: testmgr - fuzz hashes against...")
      Fixes: d435e10e ("crypto: testmgr - fuzz skciphers against...")
      Fixes: 40153b10 ("crypto: testmgr - fuzz AEADs against...")
      Reported-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Reviewed-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2bbb3375
  7. 11 12月, 2019 4 次提交
  8. 17 11月, 2019 1 次提交
  9. 13 6月, 2019 1 次提交
  10. 31 5月, 2019 1 次提交
  11. 30 5月, 2019 1 次提交
  12. 25 1月, 2019 1 次提交
  13. 11 1月, 2019 2 次提交
  14. 07 12月, 2018 6 次提交
  15. 28 9月, 2018 1 次提交
  16. 04 9月, 2018 2 次提交
  17. 21 4月, 2018 1 次提交
  18. 31 3月, 2018 1 次提交
    • H
      crypto: api - Keep failed instances alive · eb02c38f
      Herbert Xu 提交于
      This patch reverts commit 9c521a20 ("crypto: api - remove
      instance when test failed") and fixes the underlying problem
      in a different way.
      
      To recap, prior to the reverted commit, an instance that fails
      a self-test is kept around.  However, it would satisfy any new
      lookups against its name and therefore the system may accumlulate
      an unbounded number of failed instances for the same algorithm
      name.
      
      The reverted commit fixed it by unregistering the instance.  Hoever,
      this still does not prevent the creation of the same failed instance
      over and over again each time the name is looked up.
      
      This patch fixes it by keeping the failed instance around, just as
      we would if it were a normal algorithm.  However, the lookup code
      has been udpated so that we do not attempt to create another
      instance as long as this failed one is still registered.  Of course,
      you could still force a new creation by deleting the instance from
      user-space.
      
      A new error (ELIBBAD) has been commandeered for this purpose and
      will be returned when all registered algorithm of a given name
      have failed the self-test.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      eb02c38f
  19. 05 1月, 2018 3 次提交
    • E
      crypto: algapi - remove unused notifications · 8b55107c
      Eric Biggers 提交于
      There is a message posted to the crypto notifier chain when an algorithm
      is unregistered, and when a template is registered or unregistered.  But
      nothing is listening for those messages; currently there are only
      listeners for the algorithm request and registration messages.
      
      Get rid of these unused notifications for now.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8b55107c
    • E
      crypto: algapi - convert cra_refcnt to refcount_t · ce8614a3
      Eric Biggers 提交于
      Reference counters should use refcount_t rather than atomic_t, since the
      refcount_t implementation can prevent overflows, reducing the
      exploitability of reference leak bugs.  crypto_alg.cra_refcount is a
      reference counter with the usual semantics, so switch it over to
      refcount_t.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      ce8614a3
    • E
      crypto: algapi - fix NULL dereference in crypto_remove_spawns() · 9a006742
      Eric Biggers 提交于
      syzkaller triggered a NULL pointer dereference in crypto_remove_spawns()
      via a program that repeatedly and concurrently requests AEADs
      "authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)"
      through AF_ALG, where the hashes are requested as "untested"
      (CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this
      causes the template to be instantiated for every request).
      
      Although AF_ALG users really shouldn't be able to request an "untested"
      algorithm, the NULL pointer dereference is actually caused by a
      longstanding race condition where crypto_remove_spawns() can encounter
      an instance which has had spawn(s) "grabbed" but hasn't yet been
      registered, resulting in ->cra_users still being NULL.
      
      We probably should properly initialize ->cra_users earlier, but that
      would require updating many templates individually.  For now just fix
      the bug in a simple way that can easily be backported: make
      crypto_remove_spawns() treat a NULL ->cra_users list as empty.
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      9a006742
  20. 03 11月, 2017 1 次提交
    • G
      crypto: change transient busy return code to -ENOSPC · 6b80ea38
      Gilad Ben-Yossef 提交于
      The crypto API was using the -EBUSY return value to indicate
      both a hard failure to submit a crypto operation into a
      transformation provider when the latter was busy and the backlog
      mechanism was not enabled as well as a notification that the
      operation was queued into the backlog when the backlog mechanism
      was enabled.
      
      Having the same return code indicate two very different conditions
      depending on a flag is both error prone and requires extra runtime
      check like the following to discern between the cases:
      
      	if (err == -EINPROGRESS ||
      	    (err == -EBUSY && (ahash_request_flags(req) &
      			       CRYPTO_TFM_REQ_MAY_BACKLOG)))
      
      This patch changes the return code used to indicate a crypto op
      failed due to the transformation provider being transiently busy
      to -ENOSPC.
      Signed-off-by: NGilad Ben-Yossef <gilad@benyossef.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6b80ea38
  21. 04 8月, 2017 1 次提交