1. 10 1月, 2019 4 次提交
    • H
      crypto: caam - fix SHA support detection · 2dd3fde4
      Horia Geantă 提交于
      The addition of Chacha20 + Poly1305 authenc support inadvertently broke
      detection of algorithms supported by MDHA (Message Digest Hardware
      Accelerator), fix it.
      
      Fixes: d6bbd4ee ("crypto: caam/jr - add support for Chacha20 + Poly1305")
      Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2dd3fde4
    • A
      crypto: caam - fix zero-length buffer DMA mapping · 04e6d25c
      Aymen Sghaier 提交于
      Recent changes - probably DMA API related (generic and/or arm64-specific) -
      exposed a case where driver maps a zero-length buffer:
      ahash_init()->ahash_update()->ahash_final() with a zero-length string to
      hash
      
      kernel BUG at kernel/dma/swiotlb.c:475!
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 2 PID: 1823 Comm: cryptomgr_test Not tainted 4.20.0-rc1-00108-g00c9fe37 #1
      Hardware name: LS1046A RDB Board (DT)
      pstate: 80000005 (Nzcv daif -PAN -UAO)
      pc : swiotlb_tbl_map_single+0x170/0x2b8
      lr : swiotlb_map_page+0x134/0x1f8
      sp : ffff00000f79b8f0
      x29: ffff00000f79b8f0 x28: 0000000000000000
      x27: ffff0000093d0000 x26: 0000000000000000
      x25: 00000000001f3ffe x24: 0000000000200000
      x23: 0000000000000000 x22: 00000009f2c538c0
      x21: ffff800970aeb410 x20: 0000000000000001
      x19: ffff800970aeb410 x18: 0000000000000007
      x17: 000000000000000e x16: 0000000000000001
      x15: 0000000000000019 x14: c32cb8218a167fe8
      x13: ffffffff00000000 x12: ffff80097fdae348
      x11: 0000800976bca000 x10: 0000000000000010
      x9 : 0000000000000000 x8 : ffff0000091fd6c8
      x7 : 0000000000000000 x6 : 00000009f2c538bf
      x5 : 0000000000000000 x4 : 0000000000000001
      x3 : 0000000000000000 x2 : 00000009f2c538c0
      x1 : 00000000f9fff000 x0 : 0000000000000000
      Process cryptomgr_test (pid: 1823, stack limit = 0x(____ptrval____))
      Call trace:
       swiotlb_tbl_map_single+0x170/0x2b8
       swiotlb_map_page+0x134/0x1f8
       ahash_final_no_ctx+0xc4/0x6cc
       ahash_final+0x10/0x18
       crypto_ahash_op+0x30/0x84
       crypto_ahash_final+0x14/0x1c
       __test_hash+0x574/0xe0c
       test_hash+0x28/0x80
       __alg_test_hash+0x84/0xd0
       alg_test_hash+0x78/0x144
       alg_test.part.30+0x12c/0x2b4
       alg_test+0x3c/0x68
       cryptomgr_test+0x44/0x4c
       kthread+0xfc/0x128
       ret_from_fork+0x10/0x18
      Code: d34bfc18 2a1a03f7 1a9f8694 35fff89a (d4210000)
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAymen Sghaier <aymen.sghaier@nxp.com>
      Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      04e6d25c
    • E
      crypto: ccree - convert to use crypto_authenc_extractkeys() · dc95b535
      Eric Biggers 提交于
      Convert the ccree crypto driver to use crypto_authenc_extractkeys() so
      that it picks up the fix for broken validation of rtattr::rta_len.
      
      Fixes: ff27e85a ("crypto: ccree - add AEAD support")
      Cc: <stable@vger.kernel.org> # v4.17+
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      dc95b535
    • E
      crypto: bcm - convert to use crypto_authenc_extractkeys() · ab57b335
      Eric Biggers 提交于
      Convert the bcm crypto driver to use crypto_authenc_extractkeys() so
      that it picks up the fix for broken validation of rtattr::rta_len.
      
      This also fixes the DES weak key check to actually be done on the right
      key. (It was checking the authentication key, not the encryption key...)
      
      Fixes: 9d12ba86 ("crypto: brcm - Add Broadcom SPU driver")
      Cc: <stable@vger.kernel.org> # v4.11+
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      ab57b335
  2. 04 1月, 2019 1 次提交
    • L
      Remove 'type' argument from access_ok() function · 96d4f267
      Linus Torvalds 提交于
      Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
      of the user address range verification function since we got rid of the
      old racy i386-only code to walk page tables by hand.
      
      It existed because the original 80386 would not honor the write protect
      bit when in kernel mode, so you had to do COW by hand before doing any
      user access.  But we haven't supported that in a long time, and these
      days the 'type' argument is a purely historical artifact.
      
      A discussion about extending 'user_access_begin()' to do the range
      checking resulted this patch, because there is no way we're going to
      move the old VERIFY_xyz interface to that model.  And it's best done at
      the end of the merge window when I've done most of my merges, so let's
      just get this done once and for all.
      
      This patch was mostly done with a sed-script, with manual fix-ups for
      the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
      
      There were a couple of notable cases:
      
       - csky still had the old "verify_area()" name as an alias.
      
       - the iter_iov code had magical hardcoded knowledge of the actual
         values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
         really used it)
      
       - microblaze used the type argument for a debug printout
      
      but other than those oddities this should be a total no-op patch.
      
      I tried to fix up all architectures, did fairly extensive grepping for
      access_ok() uses, and the changes are trivial, but I may have missed
      something.  Any missed conversion should be trivially fixable, though.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      96d4f267
  3. 23 12月, 2018 13 次提交
  4. 21 12月, 2018 1 次提交
  5. 20 12月, 2018 2 次提交
  6. 15 12月, 2018 4 次提交
  7. 13 12月, 2018 1 次提交
  8. 07 12月, 2018 4 次提交
  9. 29 11月, 2018 2 次提交
  10. 24 11月, 2018 1 次提交
  11. 20 11月, 2018 4 次提交
  12. 16 11月, 2018 3 次提交
反馈
建议
客服 返回
顶部