Eric Lee / smarc-fsl-linux-kernel

17 Feb, 2018

1 commit

  • 2f00eb279   crypto: hash - prevent using keyed hashes without setting key ... Browse Code »

    commit 9fa68f620041be04720d0cbfb1bd3ddfc6310b24 upstream.

    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: syzbot
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     

20 Dec, 2017

1 commit

  • 902ae89f8   crypto: hmac - require that the underlying hash algorithm is unkeyed ... Browse Code »

    commit af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 upstream.

    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
    #include

    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: syzbot
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     

11 Oct, 2017

1 commit

  • b61907bb4   crypto: shash - Fix zero-length shash ahash digest crash ... Browse Code »

    The shash ahash digest adaptor function may crash if given a
    zero-length input together with a null SG list. This is because
    it tries to read the SG list before looking at the length.

    This patch fixes it by checking the length first.

    Cc:
    Reported-by: Stephan Müller
    Signed-off-by: Herbert Xu
    Tested-by: Stephan Müller

    Herbert Xu
     

07 Oct, 2017

1 commit

  • 9039f3ef4   crypto: shash - Fix a sleep-in-atomic bug in shash_setkey_unaligned ... Browse Code »

    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: Jia-Ju Bai
    Signed-off-by: Herbert Xu

    Jia-Ju Bai
     

13 Jan, 2017

1 commit

  • d8c34b949   crypto: Replaced gcc specific attributes with macros from compiler.h ... Browse Code »

    Continuing from this commit: 52f5684c8e1e
    ("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 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: Gideon Israel Dsouza
    Signed-off-by: Herbert Xu

    Gideon Israel Dsouza
     

18 Mar, 2016

1 commit

  • 70477371d   Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 ... Browse Code »

    Pull crypto update from Herbert Xu:
    "Here is the crypto update for 4.6:

    API:
    - Convert remaining crypto_hash users to shash or ahash, also convert
    blkcipher/ablkcipher users to skcipher.
    - Remove crypto_hash interface.
    - Remove crypto_pcomp interface.
    - Add crypto engine for async cipher drivers.
    - Add akcipher documentation.
    - Add skcipher documentation.

    Algorithms:
    - Rename crypto/crc32 to avoid name clash with lib/crc32.
    - Fix bug in keywrap where we zero the wrong pointer.

    Drivers:
    - Support T5/M5, T7/M7 SPARC CPUs in n2 hwrng driver.
    - Add PIC32 hwrng driver.
    - Support BCM6368 in bcm63xx hwrng driver.
    - Pack structs for 32-bit compat users in qat.
    - Use crypto engine in omap-aes.
    - Add support for sama5d2x SoCs in atmel-sha.
    - Make atmel-sha available again.
    - Make sahara hashing available again.
    - Make ccp hashing available again.
    - Make sha1-mb available again.
    - Add support for multiple devices in ccp.
    - Improve DMA performance in caam.
    - Add hashing support to rockchip"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (116 commits)
    crypto: qat - remove redundant arbiter configuration
    crypto: ux500 - fix checks of error code returned by devm_ioremap_resource()
    crypto: atmel - fix checks of error code returned by devm_ioremap_resource()
    crypto: qat - Change the definition of icp_qat_uof_regtype
    hwrng: exynos - use __maybe_unused to hide pm functions
    crypto: ccp - Add abstraction for device-specific calls
    crypto: ccp - CCP versioning support
    crypto: ccp - Support for multiple CCPs
    crypto: ccp - Remove check for x86 family and model
    crypto: ccp - memset request context to zero during import
    lib/mpi: use "static inline" instead of "extern inline"
    lib/mpi: avoid assembler warning
    hwrng: bcm63xx - fix non device tree compatibility
    crypto: testmgr - allow rfc3686 aes-ctr variants in fips mode.
    crypto: qat - The AE id should be less than the maximal AE number
    lib/mpi: Endianness fix
    crypto: rockchip - add hash support for crypto engine in rk3288
    crypto: xts - fix compile errors
    crypto: doc - add skcipher API documentation
    crypto: doc - update AEAD AD handling
    ...

    Linus Torvalds
     

06 Feb, 2016

1 commit

27 Jan, 2016

1 commit

  • 00420a65f   crypto: shash - Fix has_key setting ... Browse Code »

    The has_key logic is wrong for shash algorithms as they always
    have a setkey function. So we should instead be testing against
    shash_no_setkey.

    Fixes: a5596d633278 ("crypto: hash - Add crypto_ahash_has_setkey")
    Cc: stable@vger.kernel.org
    Reported-by: Stephan Mueller
    Signed-off-by: Herbert Xu
    Tested-by: Stephan Mueller

    Herbert Xu
     

18 Jan, 2016

1 commit

21 Apr, 2015

1 commit

08 Jun, 2014

1 commit

  • 66d8ea572   crypto: LLVMLinux: aligned-attribute.patch ... Browse Code »

    __attribute__((aligned)) applies the default alignment for the largest scalar
    type for the target ABI. gcc allows it to be applied inline to a defined type.
    Clang only allows it to be applied to a type definition (PR11071).

    Making it into 2 lines makes it more readable and works with both compilers.

    Author: Mark Charlebois
    Signed-off-by: Mark Charlebois
    Signed-off-by: Behan Webster

    Mark Charlebois
     

19 Feb, 2013

1 commit

  • 9a5467bf7   crypto: user - fix info leaks in report API ... Browse Code »

    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: Mathias Krause
    Cc: Steffen Klassert
    Signed-off-by: Herbert Xu

    Mathias Krause
     

01 Aug, 2012

1 commit

02 Apr, 2012

1 commit

20 Mar, 2012

1 commit

11 Nov, 2011

1 commit

21 Oct, 2011

1 commit

05 Nov, 2010

1 commit

19 May, 2010

1 commit

24 Jul, 2009

1 commit

22 Jul, 2009

1 commit

  • f592682f9   crypto: shash - Require all algorithms to support export/import ... Browse Code »

    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: Herbert Xu

    Herbert Xu
     

15 Jul, 2009

2 commits

14 Jul, 2009

7 commits

12 Jul, 2009

1 commit

11 Jul, 2009

2 commits

08 Jul, 2009

6 commits

27 Mar, 2009

1 commit