08 Aug, 2020

1 commit

  • As said by Linus:

    A symmetric naming is only helpful if it implies symmetries in use.
    Otherwise it's actively misleading.

    In "kzalloc()", the z is meaningful and an important part of what the
    caller wants.

    In "kzfree()", the z is actively detrimental, because maybe in the
    future we really _might_ want to use that "memfill(0xdeadbeef)" or
    something. The "zero" part of the interface isn't even _relevant_.

    The main reason that kzfree() exists is to clear sensitive information
    that should not be leaked to other future users of the same memory
    objects.

    Rename kzfree() to kfree_sensitive() to follow the example of the recently
    added kvfree_sensitive() and make the intention of the API more explicit.
    In addition, memzero_explicit() is used to clear the memory to make sure
    that it won't get optimized away by the compiler.

    The renaming is done by using the command sequence:

    git grep -w --name-only kzfree |\
    xargs sed -i 's/kzfree/kfree_sensitive/'

    followed by some editing of the kfree_sensitive() kerneldoc and adding
    a kzfree backward compatibility macro in slab.h.

    [akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
    [akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]

    Suggested-by: Joe Perches
    Signed-off-by: Waiman Long
    Signed-off-by: Andrew Morton
    Acked-by: David Howells
    Acked-by: Michal Hocko
    Acked-by: Johannes Weiner
    Cc: Jarkko Sakkinen
    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: Joe Perches
    Cc: Matthew Wilcox
    Cc: David Rientjes
    Cc: Dan Carpenter
    Cc: "Jason A . Donenfeld"
    Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
    Signed-off-by: Linus Torvalds

    Waiman Long
     

24 Feb, 2020

1 commit

  • When BIP is used to protect Beacon frames, the Timestamp field is masked
    to zero. Otherwise, the BIP processing is identical to the way it was
    already used with group-addressed Robust Management frames.

    Signed-off-by: Jouni Malinen
    Link: https://lore.kernel.org/r/20200222132548.20835-4-jouni@codeaurora.org
    Signed-off-by: Johannes Berg

    Jouni Malinen
     

19 Jun, 2019

1 commit

  • Based on 2 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation #

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 4122 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Enrico Weigelt
    Reviewed-by: Kate Stewart
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

17 Oct, 2016

1 commit

  • Some crypto implementations (such as the generic CCM wrapper in crypto/)
    use scatterlists to map fields of private data in their struct aead_req.
    This means these data structures cannot live in the vmalloc area, which
    means that they cannot live on the stack (with CONFIG_VMAP_STACK.)

    This currently occurs only with the generic software implementation, but
    the private data and usage is implementation specific, so move the whole
    data structures off the stack into heap by allocating every time we need
    to use them.

    In addition, take care not to put any of our own stack allocations into
    scatterlists. This involves reserving some extra room when allocating the
    aead_request structures, and referring to those allocations in the scatter-
    lists (while copying the data from the stack before the crypto operation)

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Johannes Berg

    Ard Biesheuvel
     

28 May, 2015

1 commit


23 Apr, 2015

1 commit


30 Mar, 2015

1 commit

  • Commit 8ade538bf39b ("mac80111: Add BIP-GMAC-128 and BIP-GMAC-256
    ciphers") had the success return in incorrect place before the
    crypto_aead_setauthsize() call which practically ended up skipping that
    call unconditionally.

    The missing call did not actually change any functionality since
    GMAC_MIC_LEN (16) is identical to the maxauthsize in gcm(aes) and as
    such, the default value used for the authsize parameter.

    Reported-by: Dan Carpenter
    Signed-off-by: Jouni Malinen
    Signed-off-by: Johannes Berg

    Jouni Malinen
     

27 Jan, 2015

1 commit