1. 30 Mar, 2018 1 commit
  2. 05 Jan, 2018 2 commits
  3. 22 Dec, 2017 1 commit
  4. 21 Oct, 2016 1 commit
  5. 25 Jan, 2016 1 commit
  6. 23 Apr, 2015 1 commit
  7. 21 Apr, 2015 1 commit
  8. 25 Jun, 2013 1 commit
    • Herbert Xu's avatar
      crypto: algboss - Hold ref count on larval · 939e1779
      Herbert Xu authored
      On Thu, Jun 20, 2013 at 10:00:21AM +0200, Daniel Borkmann wrote:
      > After having fixed a NULL pointer dereference in SCTP 1abd165e ("net:
      > sctp: fix NULL pointer dereference in socket destruction"), I ran into
      > the following NULL pointer dereference in the crypto subsystem with
      > the same reproducer, easily hit each time:
      > 
      > BUG: unable to handle kernel NULL pointer dereference at (null)
      > IP: [<ffffffff81070321>] __wake_up_common+0x31/0x90
      > PGD 0
      > Oops: 0000 [#1] SMP
      > Modules linked in: padlock_sha(F-) sha256_generic(F) sctp(F) libcrc32c(F) [..]
      > CPU: 6 PID: 3326 Comm: cryptomgr_probe Tainted: GF            3.10.0-rc5+ #1
      > Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
      > task: ffff88007b6cf4e0 ti: ffff88007b7cc000 task.ti: ffff88007b7cc000
      > RIP: 0010:[<ffffffff81070321>]  [<ffffffff81070321>] __wake_up_common+0x31/0x90
      > RSP: 0018:ffff88007b7cde08  EFLAGS: 00010082
      > RAX: ffffffffffffffe8 RBX: ffff88003756c130 RCX: 0000000000000000
      > RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88003756c130
      > RBP: ffff88007b7cde48 R08: 0000000000000000 R09: ffff88012b173200
      > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000282
      > R13: ffff88003756c138 R14: 0000000000000000 R15: 0000000000000000
      > FS:  0000000000000000(0000) GS:ffff88012fc60000(0000) knlGS:0000000000000000
      > CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      > CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000007e0
      > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      > Stack:
      >  ffff88007b7cde28 0000000300000000 ffff88007b7cde28 ffff88003756c130
      >  0000000000000282 ffff88003756c128 ffffffff81227670 0000000000000000
      >  ffff88007b7cde78 ffffffff810722b7 ffff88007cdcf000 ffffffff81a90540
      > Call Trace:
      >  [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20
      >  [<ffffffff810722b7>] complete_all+0x47/0x60
      >  [<ffffffff81227708>] cryptomgr_probe+0x98/0xc0
      >  [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20
      >  [<ffffffff8106760e>] kthread+0xce/0xe0
      >  [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70
      >  [<ffffffff815450dc>] ret_from_fork+0x7c/0xb0
      >  [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70
      > Code: 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 89 75 cc 89 55 c8
      >       4c 8d 6f 08 48 8b 57 08 41 89 cf 4d 89 c6 48 8d 42 e
      > RIP  [<ffffffff81070321>] __wake_up_common+0x31/0x90
      >  RSP <ffff88007b7cde08>
      > CR2: 0000000000000000
      > ---[ end trace b495b19270a4d37e ]---
      > 
      > My assumption is that the following is happening: the minimal SCTP
      > tool runs under ``echo 1 > /proc/sys/net/sctp/auth_enable'', hence
      > it's making use of crypto_alloc_hash() via sctp_auth_init_hmacs().
      > It forks itself, heavily allocates, binds, listens and waits in
      > accept on sctp sockets, and then randomly kills some of them (no
      > need for an actual client in this case to hit this). Then, again,
      > allocating, binding, etc, and then killing child processes.
      > 
      > The problem that might be happening here is that cryptomgr requests
      > the module to probe/load through cryptomgr_schedule_probe(), but
      > before the thread handler cryptomgr_probe() returns, we return from
      > the wait_for_completion_interruptible() function and probably already
      > have cleared up larval, thus we run into a NULL pointer dereference
      > when in cryptomgr_probe() complete_all() is being called.
      > 
      > If we wait with wait_for_completion() instead, this panic will not
      > occur anymore. This is valid, because in case a signal is pending,
      > cryptomgr_probe() returns from probing anyway with properly calling
      > complete_all().
      
      The use of wait_for_completion_interruptible is intentional so that
      we don't lock up the thread if a bug causes us to never wake up.
      
      This bug is caused by the helper thread using the larval without
      holding a reference count on it.  If the helper thread completes
      after the original thread requesting for help has gone away and
      destroyed the larval, then we get the crash above.
      
      So the fix is to hold a reference count on the larval.
      
      Cc: <stable@vger.kernel.org> # 3.6+
      Reported-by: 's avatarDaniel Borkmann <dborkman@redhat.com>
      Tested-by: 's avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      939e1779
  9. 22 Jun, 2012 1 commit
    • Herbert Xu's avatar
      crypto: algapi - Move larval completion into algboss · 39871037
      Herbert Xu authored
      It has been observed that sometimes the crypto allocation code
      will get stuck for 60 seconds or multiples thereof.  This is
      usually caused by an algorithm failing to pass the self-test.
      
      If an algorithm fails to be constructed, we will immediately notify
      all larval waiters.  However, if it succeeds in construction, but
      then fails the self-test, we won't notify anyone at all.
      
      This patch fixes this by merging the notification in the case
      where the algorithm fails to be constructed with that of the
      the case where it pases the self-test.  This way regardless of
      what happens, we'll give the larval waiters an answer.
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      39871037
  10. 21 Oct, 2011 2 commits
  11. 10 Mar, 2010 1 commit
  12. 14 Jul, 2009 2 commits
  13. 08 Jul, 2009 1 commit
  14. 18 Jun, 2009 1 commit
    • Neil Horman's avatar
      random: Add optional continuous repetition test to entropy store based rngs · 5b739ef8
      Neil Horman authored
      FIPS-140 requires that all random number generators implement continuous self
      tests in which each extracted block of data is compared against the last block
      for repetition.  The ansi_cprng implements such a test, but it would be nice if
      the hw rng's did the same thing.  Obviously its not something thats always
      needed, but it seems like it would be a nice feature to have on occasion. I've
      written the below patch which allows individual entropy stores to be flagged as
      desiring a continuous test to be run on them as is extracted.  By default this
      option is off, but is enabled in the event that fips mode is selected during
      bootup.
      Signed-off-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: 's avatarMatt Mackall <mpm@selenic.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      5b739ef8
  15. 02 Jun, 2009 1 commit
    • Herbert Xu's avatar
      crypto: testmgr - Dynamically allocate xbuf and axbuf · f8b0d4d0
      Herbert Xu authored
      We currently allocate temporary memory that is used for testing
      statically.  This renders the testing engine non-reentrant. As
      algorithms may nest, i.e., one may construct another in order to
      carry out a part of its operation, this is unacceptable.  For
      example, it has been reported that an AEAD implementation allocates
      a cipher in its setkey function, which causes it to fail during
      testing as the temporary memory is overwritten.
      
      This patch replaces the static memory with dynamically allocated
      buffers.  We need a maximum of 16 pages so this slightly increases
      the chances of an algorithm failing due to memory shortage.
      However, as testing usually occurs at registration, this shouldn't
      be a big problem.
      Reported-by: 's avatarShasi Pulijala <spulijala@amcc.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      f8b0d4d0
  16. 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
  17. 25 Dec, 2008 1 commit
    • Herbert Xu's avatar
      crypto: api - Rebirth of crypto_alloc_tfm · 7b0bac64
      Herbert Xu authored
      This patch reintroduces a completely revamped crypto_alloc_tfm.
      The biggest change is that we now take two crypto_type objects
      when allocating a tfm, a frontend and a backend.  In fact this
      simply formalises what we've been doing behind the API's back.
      
      For example, as it stands crypto_alloc_ahash may use an
      actual ahash algorithm or a crypto_hash algorithm.  Putting
      this in the API allows us to do this much more cleanly.
      
      The existing types will be converted across gradually.
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      7b0bac64
  18. 29 Aug, 2008 4 commits
  19. 10 Jul, 2008 1 commit
  20. 10 Jan, 2008 2 commits
    • Herbert Xu's avatar
      [CRYPTO] skcipher: Create default givcipher instances · b9c55aa4
      Herbert Xu authored
      This patch makes crypto_alloc_ablkcipher/crypto_grab_skcipher always
      return algorithms that are capable of generating their own IVs through
      givencrypt and givdecrypt.  Each algorithm may specify its default IV
      generator through the geniv field.
      
      For algorithms that do not set the geniv field, the blkcipher layer will
      pick a default.  Currently it's chainiv for synchronous algorithms and
      eseqiv for asynchronous algorithms.  Note that if these wrappers do not
      work on an algorithm then that algorithm must specify its own geniv or
      it can't be used at all.
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      b9c55aa4
    • Herbert Xu's avatar
      [CRYPTO] scatterwalk: Move scatterwalk.h to linux/crypto · 42c271c6
      Herbert Xu authored
      The scatterwalk infrastructure is used by algorithms so it needs to
      move out of crypto for future users that may live in drivers/crypto
      or asm/*/crypto.
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      42c271c6
  21. 10 Oct, 2007 1 commit
    • Herbert Xu's avatar
      [CRYPTO] api: Kill crypto_km_types · 70dec235
      Herbert Xu authored
      When scatterwalk is built as a module digest.c was broken because it
      requires the crypto_km_types structure which is in scatterwalk.  This
      patch removes the crypto_km_types structure by encoding the logic into
      crypto_kmap_type directly.
      
      In fact, this even saves a few bytes of code (not to mention the data
      structure itself) on i386 which is about the only place where it's
      needed.
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      70dec235
  22. 06 Feb, 2007 2 commits
  23. 21 Sep, 2006 9 commits
  24. 09 Jan, 2006 1 commit
    • Herbert Xu's avatar
      [CRYPTO] Allow multiple implementations of the same algorithm · 5cb1454b
      Herbert Xu authored
      This is the first step on the road towards asynchronous support in
      the Crypto API.  It adds support for having multiple crypto_alg objects
      for the same algorithm registered in the system.
      
      For example, each device driver would register a crypto_alg object
      for each algorithm that it supports.  While at the same time the
      user may load software implementations of those same algorithms.
      
      Users of the Crypto API may then select a specific implementation
      by name, or choose any implementation for a given algorithm with
      the highest priority.
      
      The priority field is a 32-bit signed integer.  In future it will be
      possible to modify it from user-space.
      
      This also provides a solution to the problem of selecting amongst
      various AES implementations, that is, aes vs. aes-i586 vs. aes-padlock.
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      5cb1454b