10 Sep, 2016

1 commit


10 May, 2016

1 commit

  • Stack object "dte_facilities" is allocated in x25_rx_call_request(),
    which is supposed to be initialized in x25_negotiate_facilities.
    However, 5 fields (8 bytes in total) are not initialized. This
    object is then copied to userland via copy_to_user, thus infoleak
    occurs.

    Signed-off-by: Kangjie Lu
    Signed-off-by: David S. Miller

    Kangjie Lu
     

11 May, 2015

1 commit


03 Mar, 2015

1 commit

  • After TIPC doesn't depend on iocb argument in its internal
    implementations of sendmsg() and recvmsg() hooks defined in proto
    structure, no any user is using iocb argument in them at all now.
    Then we can drop the redundant iocb argument completely from kinds of
    implementations of both sendmsg() and recvmsg() in the entire
    networking stack.

    Cc: Christoph Hellwig
    Suggested-by: Al Viro
    Signed-off-by: Ying Xue
    Signed-off-by: David S. Miller

    Ying Xue
     

24 Nov, 2014

1 commit


06 Nov, 2014

1 commit

  • This encapsulates all of the skb_copy_datagram_iovec() callers
    with call argument signature "skb, offset, msghdr->msg_iov, length".

    When we move to iov_iters in the networking, the iov_iter object will
    sit in the msghdr.

    Having a helper like this means there will be less places to touch
    during that transformation.

    Based upon descriptions and patch from Al Viro.

    Signed-off-by: David S. Miller

    David S. Miller
     

12 Apr, 2014

1 commit

  • Several spots in the kernel perform a sequence like:

    skb_queue_tail(&sk->s_receive_queue, skb);
    sk->sk_data_ready(sk, skb->len);

    But at the moment we place the SKB onto the socket receive queue it
    can be consumed and freed up. So this skb->len access is potentially
    to freed up memory.

    Furthermore, the skb->len can be modified by the consumer so it is
    possible that the value isn't accurate.

    And finally, no actual implementation of this callback actually uses
    the length argument. And since nobody actually cared about it's
    value, lots of call sites pass arbitrary values in such as '0' and
    even '1'.

    So just remove the length argument from the callback, that way there
    is no confusion whatsoever and all of these use-after-free cases get
    fixed as a side effect.

    Based upon a patch by Eric Dumazet and his suggestion to audit this
    issue tree-wide.

    Signed-off-by: David S. Miller

    David S. Miller
     

19 Jan, 2014

1 commit

  • This is a follow-up patch to f3d3342602f8bc ("net: rework recvmsg
    handler msg_name and msg_namelen logic").

    DECLARE_SOCKADDR validates that the structure we use for writing the
    name information to is not larger than the buffer which is reserved
    for msg->msg_name (which is 128 bytes). Also use DECLARE_SOCKADDR
    consistently in sendmsg code paths.

    Signed-off-by: Steffen Hurrle
    Suggested-by: Hannes Frederic Sowa
    Acked-by: Hannes Frederic Sowa
    Signed-off-by: David S. Miller

    Steffen Hurrle
     

10 Dec, 2013

1 commit


21 Nov, 2013

1 commit


30 Oct, 2013

1 commit


04 Sep, 2013

1 commit

  • This was found with a manual audit and I don't have a reproducer. We
    limit ->calling_len and ->called_len when we get them from
    copy_from_user() in x25_ioctl() so when they come from skb->data then
    we should cap them there as well.

    Signed-off-by: Dan Carpenter
    Signed-off-by: David S. Miller

    Dan Carpenter
     

02 Jul, 2013

1 commit

  • Two of the x25 ioctl cases have error paths that break out of the function without
    unlocking the socket, leading to this warning:

    ================================================
    [ BUG: lock held when returning to user space! ]
    3.10.0-rc7+ #36 Not tainted
    ------------------------------------------------
    trinity-child2/31407 is leaving the kernel with locks still held!
    1 lock held by trinity-child2/31407:
    #0: (sk_lock-AF_X25){+.+.+.}, at: [] x25_ioctl+0x8a/0x740 [x25]

    Signed-off-by: Dave Jones
    Signed-off-by: David S. Miller

    Dave Jones
     

29 May, 2013

1 commit

  • So far, only net_device * could be passed along with netdevice notifier
    event. This patch provides a possibility to pass custom structure
    able to provide info that event listener needs to know.

    Signed-off-by: Jiri Pirko

    v2->v3: fix typo on simeth
    shortened dev_getter
    shortened notifier_info struct name
    v1->v2: fix notifier_call parameter in call_netdevice_notifier()
    Signed-off-by: David S. Miller

    Jiri Pirko
     

10 Apr, 2013

1 commit


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
     

12 Jan, 2013

1 commit

  • The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
    while now and is almost always enabled by default. As agreed during the
    Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

    CC: Andrew Hendry
    CC: "David S. Miller"
    Signed-off-by: Kees Cook
    Acked-by: David S. Miller

    Kees Cook
     

11 Jul, 2012

1 commit


24 Apr, 2012

1 commit

  • sk_add_backlog() & sk_rcvqueues_full() hard coded sk_rcvbuf as the
    memory limit. We need to make this limit a parameter for TCP use.

    No functional change expected in this patch, all callers still using the
    old sk_rcvbuf limit.

    Signed-off-by: Eric Dumazet
    Cc: Neal Cardwell
    Cc: Tom Herbert
    Cc: Maciej Żenczykowski
    Cc: Yuchung Cheng
    Cc: Ilpo Järvinen
    Cc: Rick Jones
    Signed-off-by: David S. Miller

    Eric Dumazet
     

21 Apr, 2012

2 commits

  • This results in code with less boiler plate that is a bit easier
    to read.

    Additionally stops us from using compatibility code in the sysctl
    core, hastening the day when the compatibility code can be removed.

    Signed-off-by: Eric W. Biederman
    Acked-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Eric W. Biederman
     
  • This makes it clearer which sysctls are relative to your current network
    namespace.

    This makes it a little less error prone by not exposing sysctls for the
    initial network namespace in other namespaces.

    This is the same way we handle all of our other network interfaces to
    userspace and I can't honestly remember why we didn't do this for
    sysctls right from the start.

    Signed-off-by: Eric W. Biederman
    Acked-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Eric W. Biederman
     

16 Apr, 2012

1 commit


17 Dec, 2011

1 commit


07 Nov, 2011

1 commit

  • * 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
    Revert "tracing: Include module.h in define_trace.h"
    irq: don't put module.h into irq.h for tracking irqgen modules.
    bluetooth: macroize two small inlines to avoid module.h
    ip_vs.h: fix implicit use of module_get/module_put from module.h
    nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
    include: replace linux/module.h with "struct module" wherever possible
    include: convert various register fcns to macros to avoid include chaining
    crypto.h: remove unused crypto_tfm_alg_modname() inline
    uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
    pm_runtime.h: explicitly requires notifier.h
    linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
    miscdevice.h: fix up implicit use of lists and types
    stop_machine.h: fix implicit use of smp.h for smp_processor_id
    of: fix implicit use of errno.h in include/linux/of.h
    of_platform.h: delete needless include
    acpi: remove module.h include from platform/aclinux.h
    miscdevice.h: delete unnecessary inclusion of module.h
    device_cgroup.h: delete needless include
    net: sch_generic remove redundant use of
    net: inet_timewait_sock doesnt need
    ...

    Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in
    - drivers/media/dvb/frontends/dibx000_common.c
    - drivers/media/video/{mt9m111.c,ov6650.c}
    - drivers/mfd/ab3550-core.c
    - include/linux/dmaengine.h

    Linus Torvalds
     

02 Nov, 2011

1 commit

  • commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg()
    When passed bogus junk from userspace, x25->neighbour can be NULL,
    as shown in this oops..

    BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
    IP: [] x25_recvmsg+0x4d/0x280 [x25]
    PGD 1015f3067 PUD 105072067 PMD 0
    Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
    CPU 0
    Pid: 27928, comm: iknowthis Not tainted 3.1.0+ #2 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
    RIP: 0010:[] [] x25_recvmsg+0x4d/0x280 [x25]
    RSP: 0018:ffff88010c0b7cc8 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff88010c0b7d78 RCX: 0000000000000c02
    RDX: ffff88010c0b7d78 RSI: ffff88011c93dc00 RDI: ffff880103f667b0
    RBP: ffff88010c0b7d18 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff880103f667b0
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    FS: 00007f479ce7f700(0000) GS:ffff88012a600000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 000000000000001c CR3: 000000010529e000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process iknowthis (pid: 27928, threadinfo ffff88010c0b6000, task ffff880103faa4f0)
    Stack:
    0000000000000c02 0000000000000c02 ffff88010c0b7d18 ffffff958153cb37
    ffffffff8153cb60 0000000000000c02 ffff88011c93dc00 0000000000000000
    0000000000000c02 ffff88010c0b7e10 ffff88010c0b7de8 ffffffff815372c2
    Call Trace:
    [] ? sock_update_classid+0xb0/0x180
    [] sock_aio_read.part.10+0x142/0x150
    [] ? inode_has_perm+0x62/0xa0
    [] sock_aio_read+0x2d/0x40
    [] do_sync_read+0xd2/0x110
    [] ? security_file_permission+0x96/0xb0
    [] ? rw_verify_area+0x61/0x100
    [] vfs_read+0x16d/0x180
    [] sys_read+0x4d/0x90
    [] system_call_fastpath+0x16/0x1b
    Code: 8b 66 20 4c 8b 32 48 89 d3 48 89 4d b8 45 89 c7 c7 45 cc 95 ff ff ff 4d 85 e4 0f 84 ed 01 00 00 49 8b 84 24 18 05 00 00 4c 89 e7
    78 1c 01 45 19 ed 31 f6 e8 d5 37 ff e0 41 0f b6 44 24 0e 41

    Signed-off-by: Dave Jones
    Acked-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Dave Jones
     

01 Nov, 2011

1 commit


18 Oct, 2011

3 commits

  • x25_find_listener does not check that the amount of call user data given
    in the skb is big enough in per-socket comparisons, hence buffer
    overreads may occur. Fix this by adding a check.

    Signed-off-by: Matthew Daley
    Cc: Eric Dumazet
    Cc: Andrew Hendry
    Cc: stable
    Acked-by: Andrew Hendry
    Signed-off-by: David S. Miller

    Matthew Daley
     
  • There are multiple locations in the X.25 packet layer where a skb is
    assumed to be of at least a certain size and that all its data is
    currently available at skb->data. These assumptions are not checked,
    hence buffer overreads may occur. Use pskb_may_pull to check these
    minimal size assumptions and ensure that data is available at skb->data
    when necessary, as well as use skb_copy_bits where needed.

    Signed-off-by: Matthew Daley
    Cc: Eric Dumazet
    Cc: Andrew Hendry
    Cc: stable
    Acked-by: Andrew Hendry
    Signed-off-by: David S. Miller

    Matthew Daley
     
  • X.25 call user data is being copied in its entirety from incoming messages
    without consideration to the size of the destination buffers, leading to
    possible buffer overflows. Validate incoming call user data lengths before
    these copies are performed.

    It appears this issue was noticed some time ago, however nothing seemed to
    come of it: see http://www.spinics.net/lists/linux-x25/msg00043.html and
    commit 8db09f26f912f7c90c764806e804b558da520d4f.

    Signed-off-by: Matthew Daley
    Acked-by: Eric Dumazet
    Tested-by: Andrew Hendry
    Cc: stable
    Signed-off-by: David S. Miller

    Matthew Daley
     

02 Jul, 2011

1 commit


31 Mar, 2011

1 commit


05 Mar, 2011

1 commit

  • This replaces all instances of lock_kernel in x25
    with lock_sock, taking care to release the socket
    lock around sleeping functions (sock_alloc_send_skb
    and skb_recv_datagram). It is not clear whether
    this is a correct solution, but it seem to be what
    other protocols do in the same situation.

    Includes a fix suggested by Eric Dumazet.

    Signed-off-by: Arnd Bergmann
    Acked-by: David S. Miller
    Tested-by: Andrew Hendry
    Cc: linux-x25@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Cc: Eric Dumazet

    Arnd Bergmann
     

10 Feb, 2011

1 commit


08 Feb, 2011

1 commit

  • Originally x25_parse_facilities returned
    -1 for an error
    0 meaning 0 length facilities
    >0 the length of the facilities parsed.

    5ef41308f94dc ("x25: Prevent crashing when parsing bad X.25 facilities") introduced more
    error checking in x25_parse_facilities however used 0 to indicate bad parsing
    a6331d6f9a429 ("memory corruption in X.25 facilities parsing") followed this further for
    DTE facilities, again using 0 for bad parsing.

    The meaning of 0 got confused in the callers.
    If the facilities are messed up we can't determine where the data starts.
    So patch makes all parsing errors return -1 and ensures callers close and don't use the skb further.

    Reported-by: Andy Whitcroft
    Signed-off-by: Andrew Hendry
    Signed-off-by: David S. Miller

    andrew hendry
     

09 Dec, 2010

2 commits


29 Nov, 2010

4 commits