14 Jul, 2020

1 commit


09 Oct, 2019

1 commit

  • syzbot reported:

    BUG: memory leak
    unreferenced object 0xffff888116270800 (size 224):
    comm "syz-executor641", pid 7047, jiffies 4294947360 (age 13.860s)
    hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00 20 e1 2a 81 88 ff ff 00 40 3d 2a 81 88 ff ff . .*.....@=*....
    backtrace:
    [] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
    [] slab_post_alloc_hook mm/slab.h:439 [inline]
    [] slab_alloc_node mm/slab.c:3269 [inline]
    [] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
    [] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198
    [] alloc_skb include/linux/skbuff.h:1058 [inline]
    [] alloc_skb_with_frags+0x5f/0x250 net/core/skbuff.c:5327
    [] sock_alloc_send_pskb+0x269/0x2a0 net/core/sock.c:2225
    [] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242
    [] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
    [] sock_sendmsg_nosec net/socket.c:652 [inline]
    [] sock_sendmsg+0x54/0x70 net/socket.c:671
    [] __sys_sendto+0x148/0x1f0 net/socket.c:1964
    [...]

    The bug is that llc_sap_state_process() always takes an extra reference
    to the skb, but sometimes neither llc_sap_next_state() nor
    llc_sap_state_process() itself drops this reference.

    Fix it by changing llc_sap_next_state() to never consume a reference to
    the skb, rather than sometimes do so and sometimes not. Then remove the
    extra skb_get() and kfree_skb() from llc_sap_state_process().

    Reported-by: syzbot+6bf095f9becf5efef645@syzkaller.appspotmail.com
    Reported-by: syzbot+31c16aa4202dace3812e@syzkaller.appspotmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Biggers
    Signed-off-by: Jakub Kicinski

    Eric Biggers
     

12 Mar, 2018

1 commit

  • Avoid a VLA[1] by using a real constant expression instead of a variable.
    The compiler should be able to optimize the original code and avoid using
    an actual VLA. Anyway this change is useful because it will avoid a false
    positive with -Wvla, it might also help the compiler generating better
    code.

    [1] https://lkml.org/lkml/2018/3/7/621

    Signed-off-by: Salvatore Mesoraca
    Signed-off-by: David S. Miller

    Salvatore Mesoraca
     

01 Jul, 2017

1 commit

  • refcount_t type and corresponding API should be
    used instead of atomic_t when the variable is used as
    a reference counter. This allows to avoid accidental
    refcounter overflows that might lead to use-after-free
    situations.

    This patch uses refcount_inc_not_zero() instead of
    atomic_inc_not_zero_hint() due to absense of a _hint()
    version of refcount API. If the hint() version must
    be used, we might need to revisit API.

    Signed-off-by: Elena Reshetova
    Signed-off-by: Hans Liljestrand
    Signed-off-by: Kees Cook
    Signed-off-by: David Windsor
    Signed-off-by: David S. Miller

    Reshetova, Elena
     

19 Apr, 2017

1 commit

  • A group of Linux kernel hackers reported chasing a bug that resulted
    from their assumption that SLAB_DESTROY_BY_RCU provided an existence
    guarantee, that is, that no block from such a slab would be reallocated
    during an RCU read-side critical section. Of course, that is not the
    case. Instead, SLAB_DESTROY_BY_RCU only prevents freeing of an entire
    slab of blocks.

    However, there is a phrase for this, namely "type safety". This commit
    therefore renames SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU in order
    to avoid future instances of this sort of confusion.

    Signed-off-by: Paul E. McKenney
    Cc: Christoph Lameter
    Cc: Pekka Enberg
    Cc: David Rientjes
    Cc: Joonsoo Kim
    Cc: Andrew Morton
    Cc:
    Acked-by: Johannes Weiner
    Acked-by: Vlastimil Babka
    [ paulmck: Add comments mentioning the old name, as requested by Eric
    Dumazet, in order to help people familiar with the old name find
    the new one. ]
    Acked-by: David Rientjes

    Paul E. McKenney
     

13 Feb, 2017

1 commit

  • It seems nobody used LLC since linux-3.12.

    Fortunately fuzzers like syzkaller still know how to run this code,
    otherwise it would be no fun.

    Setting skb->sk without skb->destructor leads to all kinds of
    bugs, we now prefer to be very strict about it.

    Ideally here we would use skb_set_owner() but this helper does not exist yet,
    only CAN seems to have a private helper for that.

    Fixes: 376c7311bdb6 ("net: add a temporary sanity check in skb_orphan()")
    Signed-off-by: Eric Dumazet
    Reported-by: Andrey Konovalov
    Signed-off-by: David S. Miller

    Eric Dumazet
     

11 Dec, 2014

1 commit


28 Dec, 2013

1 commit


04 Sep, 2013

1 commit

  • Convert the llc_ static inlines to the
    equivalents from etherdevice.h and remove
    the llc_ static inline functions.

    llc_mac_null -> is_zero_ether_addr
    llc_mac_multicast -> is_multicast_ether_addr
    llc_mac_match -> ether_addr_equal

    Signed-off-by: Joe Perches
    Signed-off-by: David S. Miller

    Joe Perches
     

28 Feb, 2013

1 commit

  • I'm not sure why, but the hlist for each entry iterators were conceived

    list_for_each_entry(pos, head, member)

    The hlist ones were greedy and wanted an extra parameter:

    hlist_for_each_entry(tpos, pos, head, member)

    Why did they need an extra pos parameter? I'm not quite sure. Not only
    they don't really need it, it also prevents the iterator from looking
    exactly like the list iterator, which is unfortunate.

    Besides the semantic patch, there was some manual work required:

    - Fix up the actual hlist iterators in linux/list.h
    - Fix up the declaration of other iterators based on the hlist ones.
    - A very small amount of places were using the 'node' parameter, this
    was modified to use 'obj->member' instead.
    - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
    properly, so those had to be fixed up manually.

    The semantic patch which is mostly the work of Peter Senna Tschudin is here:

    @@
    iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;

    type T;
    expression a,c,d,e;
    identifier b;
    statement S;
    @@

    -T b;

    [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
    [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
    [akpm@linux-foundation.org: checkpatch fixes]
    [akpm@linux-foundation.org: fix warnings]
    [akpm@linux-foudnation.org: redo intrusive kvm changes]
    Tested-by: Peter Senna Tschudin
    Acked-by: Paul E. McKenney
    Signed-off-by: Sasha Levin
    Cc: Wu Fengguang
    Cc: Marcelo Tosatti
    Cc: Gleb Natapov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sasha Levin
     

16 May, 2012

1 commit

  • We are going to delete the Token ring support. This removes any
    special processing in the core networking for token ring, (aside
    from net/tr.c itself), leaving the drivers and remaining tokenring
    support present but inert.

    The mass removal of the drivers and net/tr.c will be in a separate
    commit, so that the history of these files that we still care
    about won't have the giant deletion tied into their history.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

10 May, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

27 Dec, 2009

4 commits

  • For the cases where a lot of interfaces are used in conjunction with a
    lot of LLC sockets bound to the same SAP, the iteration of the socket
    list becomes prohibitively expensive.

    Replacing the list with a a local address based hash significantly
    improves the bind and listener lookup operations as well as the
    datagram delivery.

    Connected sockets delivery is also improved, but this patch does not
    address the case where we have lots of sockets with the same local
    address connected to different remote addresses.

    In order to keep the socket sanity checks alive and fast a socket
    counter was added to the SAP structure.

    Signed-off-by: Octavian Purdila
    Signed-off-by: David S. Miller

    Octavian Purdila
     
  • This patch adds a per SAP device based hash table to solve the
    multicast delivery scalability issue when we have large number of
    interfaces and a large number of sockets bound to the same SAP.

    Signed-off-by: Octavian Purdila
    Signed-off-by: David S. Miller

    Octavian Purdila
     
  • Optimize multicast delivery by doing the actual delivery without
    holding the lock. Based on the same approach used in UDP code.

    Signed-off-by: Octavian Purdila
    Signed-off-by: David S. Miller

    Octavian Purdila
     
  • For the reclamation phase we use the SLAB_DESTROY_BY_RCU mechanism,
    which require some extra checks in the lookup code:

    a) If the current socket was released, reallocated & inserted in
    another list it will short circuit the iteration for the current list,
    thus we need to restart the lookup.

    b) If the current socket was released, reallocated & inserted in the
    same list we just need to recheck it matches the look-up criteria and
    if not we can skip to the next element.

    In this case there is no need to restart the lookup, since sockets are
    inserted at the start of the list and the worst that will happen is
    that we will iterate throught some of the list elements more then
    once.

    Note that the /proc and multicast delivery was not yet converted to
    RCU, it still uses spinlocks for protection.

    Signed-off-by: Octavian Purdila
    Signed-off-by: David S. Miller

    Octavian Purdila
     

30 May, 2008

1 commit

  • llc_sap_rcv was being preceded by skb_set_owner_r, then calling
    llc_state_process that calls sock_queue_rcv_skb, that in turn calls
    skb_set_owner_r again making the space allowed to be used by the socket to be
    leaked, making the socket to get stuck.

    Fix it by setting skb->sk at llc_sap_rcv and leave the accounting to be done
    only at sock_queue_rcv_skb.

    Reported-by: Dmitry Petukhov
    Tested-by: Dmitry Petukhov
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

01 Apr, 2008

1 commit

  • Allocate the skb for llc responses with the received packet size by
    using the size adjustable llc_frame_alloc.
    Don't allocate useless extra payload.
    Cleanup magic numbers.

    So, this fixes oops.
    Reported by Jim Westfall:
    kernel: skb_over_panic: text:c0541fc7 len:1000 put:997 head:c166ac00 data:c166ac2f tail:0xc166b017 end:0xc166ac80 dev:eth0
    kernel: ------------[ cut here ]------------
    kernel: kernel BUG at net/core/skbuff.c:95!

    Signed-off-by: Joonwoo Park
    Acked-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Joonwoo Park
     

26 Apr, 2007

3 commits

  • For the common, open coded 'skb->h.raw = skb->data' operation, so that we can
    later turn skb->h.raw into a offset, reducing the size of struct sk_buff in
    64bit land while possibly keeping it as a pointer on 32bit.

    This one touches just the most simple cases:

    skb->h.raw = skb->data;
    skb->h.raw = {skb_push|[__]skb_pull}()

    The next ones will handle the slightly more "complex" cases.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • For the common, open coded 'skb->nh.raw = skb->data' operation, so that we can
    later turn skb->nh.raw into a offset, reducing the size of struct sk_buff in
    64bit land while possibly keeping it as a pointer on 32bit.

    This one touches just the most simple case, next will handle the slightly more
    "complex" cases.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • skb->head is equal to skb->data after alloc_skb, so reset the mac header while
    this is true, i.e. before skb_reserve.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

11 Feb, 2007

1 commit


14 Aug, 2006

1 commit

  • Fix from Aji_Srinivas@emc.com, STP packets are incorrectly received on
    all LLC datagram sockets, whichever interface they are bound to. The
    llc_sap datagram receive logic sends packets with a unicast
    destination MAC to one socket bound to that SAP and MAC, and multicast
    packets to all sockets bound to that SAP. STP packets are multicast,
    and we do need to know on which interface they were received.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Stephen Hemminger
     

05 Aug, 2006

1 commit

  • The datagram interface of LLC is broken in a couple of ways.
    These were discovered when trying to use it to build an out-of-kernel
    version of STP.

    First it didn't pass the source address of the received packet
    in recvfrom(). It needs to copy the source address of received LLC packets
    into the socket control block. At the same time fix a security issue
    because there was uninitialized data leakage. Every recvfrom call
    was just copying out old data.

    Second, LLC should not merge multiple packets in one receive call
    on datagram sockets. LLC should preserve packet boundaries on
    SOCK_DGRAM.

    This fix goes against the old historical comments about UNIX98 semantics
    but without this fix SOCK_DGRAM is broken and useless. So either ANK's
    interpretation was incorect or UNIX98 standard was wrong.

    Signed-off-by: Stephen Hemminger
    Acked-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Stephen Hemminger
     

18 Jun, 2006

1 commit


22 Sep, 2005

4 commits


30 Aug, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds