Eric Lee / smarc-fsl-linux-kernel

18 Aug, 2018

2 commits

  • e7aefb13e   crypto: vmac - separate tfm and request context ... Browse Code »

    commit bb29648102335586e9a66289a1d98a0cb392b6e5 upstream.

    syzbot reported a crash in vmac_final() when multiple threads
    concurrently use the same "vmac(aes)" transform through AF_ALG. The bug
    is pretty fundamental: the VMAC template doesn't separate per-request
    state from per-tfm (per-key) state like the other hash algorithms do,
    but rather stores it all in the tfm context. That's wrong.

    Also, vmac_final() incorrectly zeroes most of the state including the
    derived keys and cached pseudorandom pad. Therefore, only the first
    VMAC invocation with a given key calculates the correct digest.

    Fix these bugs by splitting the per-tfm state from the per-request state
    and using the proper init/update/final sequencing for requests.

    Reproducer for the crash:

    #include
    #include
    #include

    int main()
    {
    int fd;
    struct sockaddr_alg addr = {
    .salg_type = "hash",
    .salg_name = "vmac(aes)",
    };
    char buf[256] = { 0 };

    fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
    bind(fd, (void *)&addr, sizeof(addr));
    setsockopt(fd, SOL_ALG, ALG_SET_KEY, buf, 16);
    fork();
    fd = accept(fd, NULL, NULL);
    for (;;)
    write(fd, buf, 256);
    }

    The immediate cause of the crash is that vmac_ctx_t.partial_size exceeds
    VMAC_NHBYTES, causing vmac_final() to memset() a negative length.

    Reported-by: syzbot+264bca3a6e8d645550d3@syzkaller.appspotmail.com
    Fixes: f1939f7c5645 ("crypto: vmac - New hash algorithm for intel_txt support")
    Cc: # v2.6.32+
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     
  • ef70d1455   crypto: vmac - require a block cipher with 128-bit block size ... Browse Code »

    commit 73bf20ef3df262026c3470241ae4ac8196943ffa upstream.

    The VMAC template assumes the block cipher has a 128-bit block size, but
    it failed to check for that. Thus it was possible to instantiate it
    using a 64-bit block size cipher, e.g. "vmac(cast5)", causing
    uninitialized memory to be used.

    Add the needed check when instantiating the template.

    Fixes: f1939f7c5645 ("crypto: vmac - New hash algorithm for intel_txt support")
    Cc: # v2.6.32+
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     

26 Nov, 2014

1 commit

  • 4943ba16b   crypto: include crypto- module prefix in template ... Browse Code »

    This adds the module loading prefix "crypto-" to the template lookup
    as well.

    For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
    includes the "crypto-" prefix at every level, correctly rejecting "vfat":

    net-pf-38
    algif-hash
    crypto-vfat(blowfish)
    crypto-vfat(blowfish)-all
    crypto-vfat

    Reported-by: Mathias Krause
    Signed-off-by: Kees Cook
    Acked-by: Mathias Krause
    Signed-off-by: Herbert Xu

    Kees Cook
     

17 Oct, 2014

1 commit

  • 7185ad267   crypto: memzero_explicit - make sure to clear out sensitive data ... Browse Code »

    Recently, in commit 13aa93c70e71 ("random: add and use memzero_explicit()
    for clearing data"), we have found that GCC may optimize some memset()
    cases away when it detects a stack variable is not being used anymore
    and going out of scope. This can happen, for example, in cases when we
    are clearing out sensitive information such as keying material or any
    e.g. intermediate results from crypto computations, etc.

    With the help of Coccinelle, we can figure out and fix such occurences
    in the crypto subsytem as well. Julia Lawall provided the following
    Coccinelle program:

    @@
    type T;
    identifier x;
    @@

    T x;
    ... when exists
    when any
    -memset
    +memzero_explicit
    (&x,
    -0,
    ...)
    ... when != x
    when strict

    @@
    type T;
    identifier x;
    @@

    T x[...];
    ... when exists
    when any
    -memset
    +memzero_explicit
    (x,
    -0,
    ...)
    ... when != x
    when strict

    Therefore, make use of the drop-in replacement memzero_explicit() for
    exactly such cases instead of using memset().

    Signed-off-by: Daniel Borkmann
    Cc: Julia Lawall
    Cc: Herbert Xu
    Cc: Theodore Ts'o
    Cc: Hannes Frederic Sowa
    Acked-by: Hannes Frederic Sowa
    Acked-by: Herbert Xu
    Signed-off-by: Theodore Ts'o

    Daniel Borkmann
     

15 Oct, 2012

1 commit

  • ba1ee0709   crypto: vmac - Make VMAC work when blocks aren't aligned ... Browse Code »

    VMAC implementation, as it is, does not work with blocks that
    are not multiples of 128-bytes. Furthermore, this is a problem
    when using the implementation on scatterlists, even
    when the complete plain text is 128-byte multiple, as the pieces
    that get passed to vmac_update can be pretty much any size.

    I also added test cases for unaligned blocks.

    Signed-off-by: Salman Qazi
    Signed-off-by: Herbert Xu

    Salman Qazi
     

07 Sep, 2012

1 commit

01 Nov, 2011

1 commit

31 Mar, 2011

1 commit

18 Mar, 2010

1 commit

02 Sep, 2009

1 commit