Eric Lee / smarc-fsl-linux-kernel

08 Aug, 2020

1 commit

  • 453431a54   mm, treewide: rename kzfree() to kfree_sensitive() ... Browse Code »

    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
     

26 Jul, 2020

1 commit

  • a57066b1a   Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net ... Browse Code »

    The UDP reuseport conflict was a little bit tricky.

    The net-next code, via bpf-next, extracted the reuseport handling
    into a helper so that the BPF sk lookup code could invoke it.

    At the same time, the logic for reuseport handling of unconnected
    sockets changed via commit efc6b6f6c3113e8b203b9debfb72d81e0f3dcace
    which changed the logic to carry on the reuseport result into the
    rest of the lookup loop if we do not return immediately.

    This requires moving the reuseport_has_conns() logic into the callers.

    While we are here, get rid of inline directives as they do not belong
    in foo.c files.

    The other changes were cases of more straightforward overlapping
    modifications.

    Signed-off-by: David S. Miller

    David S. Miller
     

25 Jul, 2020

3 commits

  • 623b57bec   sctp: remove redundant initialization of variable status ... Browse Code »

    The variable status is being initialized with a value that is never read
    and it is being updated later with a new value. The initialization is
    redundant and can be removed. Also put the variable declarations into
    reverse christmas tree order.

    Addresses-Coverity: ("Unused value")
    Signed-off-by: Colin Ian King
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller

    Colin Ian King
     
  • dfd3d5266   sctp: fix slab-out-of-bounds in SCTP_DELAYED_SACK processing ... Browse Code »

    This sockopt accepts two kinds of parameters, using struct
    sctp_sack_info and struct sctp_assoc_value. The mentioned commit didn't
    notice an implicit cast from the smaller (latter) struct to the bigger
    one (former) when copying the data from the user space, which now leads
    to an attempt to write beyond the buffer (because it assumes the storing
    buffer is bigger than the parameter itself).

    Fix it by allocating a sctp_sack_info on stack and filling it out based
    on the small struct for the compat case.

    Changelog stole from an earlier patch from Marcelo Ricardo Leitner.

    Fixes: ebb25defdc17 ("sctp: pass a kernel pointer to sctp_setsockopt_delayed_ack")
    Reported-by: syzbot+0e4699d000d8b874d8dc@syzkaller.appspotmail.com
    Signed-off-by: Christoph Hellwig
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller

    Christoph Hellwig
     
  • a7b75c5a8   net: pass a sockptr_t into ->setsockopt ... Browse Code »

    Rework the remaining setsockopt code to pass a sockptr_t instead of a
    plain user pointer. This removes the last remaining set_fs(KERNEL_DS)
    outside of architecture specific code.

    Signed-off-by: Christoph Hellwig
    Acked-by: Stefan Schmidt [ieee802154]
    Acked-by: Matthieu Baerts
    Signed-off-by: David S. Miller

    Christoph Hellwig
     

23 Jul, 2020

2 commits

  • 3ecdda3e9   sctp: shrink stream outq when fails to do addstream reconf ... Browse Code »

    When adding a stream with stream reconf, the new stream firstly is in
    CLOSED state but new out chunks can still be enqueued. Then once gets
    the confirmation from the peer, the state will change to OPEN.

    However, if the peer denies, it needs to roll back the stream. But when
    doing that, it only sets the stream outcnt back, and the chunks already
    in the new stream don't get purged. It caused these chunks can still be
    dequeued in sctp_outq_dequeue_data().

    As its stream is still in CLOSE, the chunk will be enqueued to the head
    again by sctp_outq_head_data(). This chunk will never be sent out, and
    the chunks after it can never be dequeued. The assoc will be 'hung' in
    a dead loop of sending this chunk.

    To fix it, this patch is to purge these chunks already in the new
    stream by calling sctp_stream_shrink_out() when failing to do the
    addstream reconf.

    Fixes: 11ae76e67a17 ("sctp: implement receiver-side procedures for the Reconf Response Parameter")
    Reported-by: Ying Xu
    Signed-off-by: Xin Long
    Signed-off-by: David S. Miller

    Xin Long
     
  • 8f13399db   sctp: shrink stream outq only when new outcnt < old outcnt ... Browse Code »

    It's not necessary to go list_for_each for outq->out_chunk_list
    when new outcnt >= old outcnt, as no chunk with higher sid than
    new (outcnt - 1) exists in the outqueue.

    While at it, also move the list_for_each code in a new function
    sctp_stream_shrink_out(), which will be used in the next patch.

    Signed-off-by: Xin Long
    Signed-off-by: David S. Miller

    Xin Long
     

20 Jul, 2020

33 commits