25 Jul, 2020

1 commit

  • 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
     

25 Feb, 2020

1 commit

  • All of these cases are strictly of the form:

    preempt_disable();
    BPF_PROG_RUN(...);
    preempt_enable();

    Replace this with bpf_prog_run_pin_on_cpu() which wraps BPF_PROG_RUN()
    with:

    migrate_disable();
    BPF_PROG_RUN(...);
    migrate_enable();

    On non RT enabled kernels this maps to preempt_disable/enable() and on RT
    enabled kernels this solely prevents migration, which is sufficient as
    there is no requirement to prevent reentrancy to any BPF program from a
    preempting task. The only requirement is that the program stays on the same
    CPU.

    Therefore, this is a trivially correct transformation.

    The seccomp loop does not need protection over the loop. It only needs
    protection per BPF filter program

    [ tglx: Converted to bpf_prog_run_pin_on_cpu() ]

    Signed-off-by: David S. Miller
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Alexei Starovoitov
    Link: https://lore.kernel.org/bpf/20200224145643.691493094@linutronix.de

    David Miller
     

27 Sep, 2019

1 commit

  • After commit a2c11b034142 ("kcm: use BPF_PROG_RUN")
    syzbot easily triggers the warning in cant_sleep().

    As explained in commit 6cab5e90ab2b ("bpf: run bpf programs
    with preemption disabled") we need to disable preemption before
    running bpf programs.

    BUG: assuming atomic context at net/kcm/kcmsock.c:382
    in_atomic(): 0, irqs_disabled(): 0, pid: 7, name: kworker/u4:0
    3 locks held by kworker/u4:0/7:
    #0: ffff888216726128 ((wq_completion)kstrp){+.+.}, at: __write_once_size include/linux/compiler.h:226 [inline]
    #0: ffff888216726128 ((wq_completion)kstrp){+.+.}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
    #0: ffff888216726128 ((wq_completion)kstrp){+.+.}, at: atomic64_set include/asm-generic/atomic-instrumented.h:855 [inline]
    #0: ffff888216726128 ((wq_completion)kstrp){+.+.}, at: atomic_long_set include/asm-generic/atomic-long.h:40 [inline]
    #0: ffff888216726128 ((wq_completion)kstrp){+.+.}, at: set_work_data kernel/workqueue.c:620 [inline]
    #0: ffff888216726128 ((wq_completion)kstrp){+.+.}, at: set_work_pool_and_clear_pending kernel/workqueue.c:647 [inline]
    #0: ffff888216726128 ((wq_completion)kstrp){+.+.}, at: process_one_work+0x88b/0x1740 kernel/workqueue.c:2240
    #1: ffff8880a989fdc0 ((work_completion)(&strp->work)){+.+.}, at: process_one_work+0x8c1/0x1740 kernel/workqueue.c:2244
    #2: ffff888098998d10 (sk_lock-AF_INET){+.+.}, at: lock_sock include/net/sock.h:1522 [inline]
    #2: ffff888098998d10 (sk_lock-AF_INET){+.+.}, at: strp_sock_lock+0x2e/0x40 net/strparser/strparser.c:440
    CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 5.3.0+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: kstrp strp_work
    Call Trace:
    __dump_stack lib/dump_stack.c:77 [inline]
    dump_stack+0x172/0x1f0 lib/dump_stack.c:113
    __cant_sleep kernel/sched/core.c:6826 [inline]
    __cant_sleep.cold+0xa4/0xbc kernel/sched/core.c:6803
    kcm_parse_func_strparser+0x54/0x200 net/kcm/kcmsock.c:382
    __strp_recv+0x5dc/0x1b20 net/strparser/strparser.c:221
    strp_recv+0xcf/0x10b net/strparser/strparser.c:343
    tcp_read_sock+0x285/0xa00 net/ipv4/tcp.c:1639
    strp_read_sock+0x14d/0x200 net/strparser/strparser.c:366
    do_strp_work net/strparser/strparser.c:414 [inline]
    strp_work+0xe3/0x130 net/strparser/strparser.c:423
    process_one_work+0x9af/0x1740 kernel/workqueue.c:2269

    Fixes: a2c11b034142 ("kcm: use BPF_PROG_RUN")
    Fixes: 6cab5e90ab2b ("bpf: run bpf programs with preemption disabled")
    Signed-off-by: Eric Dumazet
    Reported-by: syzbot
    Signed-off-by: David S. Miller

    Eric Dumazet
     

07 Sep, 2019

1 commit


31 Jul, 2019

1 commit


23 Jul, 2019

1 commit


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
     

02 Apr, 2019

1 commit

  • When kcm is loaded while many processes try to create a KCM socket, a
    crash occurs:
    BUG: unable to handle kernel NULL pointer dereference at 000000000000000e
    IP: mutex_lock+0x27/0x40 kernel/locking/mutex.c:240
    PGD 8000000016ef2067 P4D 8000000016ef2067 PUD 3d6e9067 PMD 0
    Oops: 0002 [#1] SMP KASAN PTI
    CPU: 0 PID: 7005 Comm: syz-executor.5 Not tainted 4.12.14-396-default #1 SLE15-SP1 (unreleased)
    RIP: 0010:mutex_lock+0x27/0x40 kernel/locking/mutex.c:240
    RSP: 0018:ffff88000d487a00 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 000000000000000e RCX: 1ffff100082b0719
    ...
    CR2: 000000000000000e CR3: 000000004b1bc003 CR4: 0000000000060ef0
    Call Trace:
    kcm_create+0x600/0xbf0 [kcm]
    __sock_create+0x324/0x750 net/socket.c:1272
    ...

    This is due to race between sock_create and unfinished
    register_pernet_device. kcm_create tries to do "net_generic(net,
    kcm_net_id)". but kcm_net_id is not initialized yet.

    So switch the order of the two to close the race.

    This can be reproduced with mutiple processes doing socket(PF_KCM, ...)
    and one process doing module removal.

    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Reviewed-by: Michal Kubecek
    Signed-off-by: Jiri Slaby
    Signed-off-by: David S. Miller

    Jiri Slaby
     

24 Feb, 2019

1 commit


25 Jul, 2018

1 commit


29 Jun, 2018

1 commit

  • The poll() changes were not well thought out, and completely
    unexplained. They also caused a huge performance regression, because
    "->poll()" was no longer a trivial file operation that just called down
    to the underlying file operations, but instead did at least two indirect
    calls.

    Indirect calls are sadly slow now with the Spectre mitigation, but the
    performance problem could at least be largely mitigated by changing the
    "->get_poll_head()" operation to just have a per-file-descriptor pointer
    to the poll head instead. That gets rid of one of the new indirections.

    But that doesn't fix the new complexity that is completely unwarranted
    for the regular case. The (undocumented) reason for the poll() changes
    was some alleged AIO poll race fixing, but we don't make the common case
    slower and more complex for some uncommon special case, so this all
    really needs way more explanations and most likely a fundamental
    redesign.

    [ This revert is a revert of about 30 different commits, not reverted
    individually because that would just be unnecessarily messy - Linus ]

    Cc: Al Viro
    Cc: Christoph Hellwig
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

05 Jun, 2018

1 commit

  • Pull aio updates from Al Viro:
    "Majority of AIO stuff this cycle. aio-fsync and aio-poll, mostly.

    The only thing I'm holding back for a day or so is Adam's aio ioprio -
    his last-minute fixup is trivial (missing stub in !CONFIG_BLOCK case),
    but let it sit in -next for decency sake..."

    * 'work.aio-1' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (46 commits)
    aio: sanitize the limit checking in io_submit(2)
    aio: fold do_io_submit() into callers
    aio: shift copyin of iocb into io_submit_one()
    aio_read_events_ring(): make a bit more readable
    aio: all callers of aio_{read,write,fsync,poll} treat 0 and -EIOCBQUEUED the same way
    aio: take list removal to (some) callers of aio_complete()
    aio: add missing break for the IOCB_CMD_FDSYNC case
    random: convert to ->poll_mask
    timerfd: convert to ->poll_mask
    eventfd: switch to ->poll_mask
    pipe: convert to ->poll_mask
    crypto: af_alg: convert to ->poll_mask
    net/rxrpc: convert to ->poll_mask
    net/iucv: convert to ->poll_mask
    net/phonet: convert to ->poll_mask
    net/nfc: convert to ->poll_mask
    net/caif: convert to ->poll_mask
    net/bluetooth: convert to ->poll_mask
    net/sctp: convert to ->poll_mask
    net/tipc: convert to ->poll_mask
    ...

    Linus Torvalds
     

01 Jun, 2018

1 commit

  • (resend for properly queueing in patchwork)

    kcm_clone() creates kernel socket, which does not take net counter.
    Thus, the net may die before the socket is completely destructed,
    i.e. kcm_exit_net() is executed before kcm_done().

    Reported-by: syzbot+5f1a04e374a635efc426@syzkaller.appspotmail.com
    Signed-off-by: Kirill Tkhai
    Signed-off-by: David S. Miller

    Kirill Tkhai
     

26 May, 2018

1 commit


28 Mar, 2018

1 commit


23 Mar, 2018

1 commit

  • Fun set of conflict resolutions here...

    For the mac80211 stuff, these were fortunately just parallel
    adds. Trivially resolved.

    In drivers/net/phy/phy.c we had a bug fix in 'net' that moved the
    function phy_disable_interrupts() earlier in the file, whilst in
    'net-next' the phy_error() call from this function was removed.

    In net/ipv4/xfrm4_policy.c, David Ahern's changes to remove the
    'rt_table_id' member of rtable collided with a bug fix in 'net' that
    added a new struct member "rt_mtu_locked" which needs to be copied
    over here.

    The mlxsw driver conflict consisted of net-next separating
    the span code and definitions into separate files, whilst
    a 'net' bug fix made some changes to that moved code.

    The mlx5 infiniband conflict resolution was quite non-trivial,
    the RDMA tree's merge commit was used as a guide here, and
    here are their notes:

    ====================

    Due to bug fixes found by the syzkaller bot and taken into the for-rc
    branch after development for the 4.17 merge window had already started
    being taken into the for-next branch, there were fairly non-trivial
    merge issues that would need to be resolved between the for-rc branch
    and the for-next branch. This merge resolves those conflicts and
    provides a unified base upon which ongoing development for 4.17 can
    be based.

    Conflicts:
    drivers/infiniband/hw/mlx5/main.c - Commit 42cea83f9524
    (IB/mlx5: Fix cleanup order on unload) added to for-rc and
    commit b5ca15ad7e61 (IB/mlx5: Add proper representors support)
    add as part of the devel cycle both needed to modify the
    init/de-init functions used by mlx5. To support the new
    representors, the new functions added by the cleanup patch
    needed to be made non-static, and the init/de-init list
    added by the representors patch needed to be modified to
    match the init/de-init list changes made by the cleanup
    patch.
    Updates:
    drivers/infiniband/hw/mlx5/mlx5_ib.h - Update function
    prototypes added by representors patch to reflect new function
    names as changed by cleanup patch
    drivers/infiniband/hw/mlx5/ib_rep.c - Update init/de-init
    stage list to match new order from cleanup patch
    ====================

    Signed-off-by: David S. Miller

    David S. Miller
     

16 Mar, 2018

1 commit

  • Need to lock lower socket in order to provide mutual exclusion
    with kcm_unattach.

    v2: Add Reported-by for syzbot

    Fixes: ab7ac4eb9832e32a09f4e804 ("kcm: Kernel Connection Multiplexor module")
    Reported-by: syzbot+ea75c0ffcd353d32515f064aaebefc5279e6161e@syzkaller.appspotmail.com
    Signed-off-by: Tom Herbert
    Signed-off-by: David S. Miller

    Tom Herbert
     

28 Feb, 2018

1 commit

  • These pernet_operations make pretty simple actions
    like variable initialization on init, debug checks
    on exit, and so on, and they obviously are able
    to be executed in parallel with any others:

    vrf_net_ops
    lockd_net_ops
    grace_net_ops
    xfrm6_tunnel_net_ops
    kcm_net_ops
    tcf_net_ops

    Signed-off-by: Kirill Tkhai
    Signed-off-by: David S. Miller

    Kirill Tkhai
     

15 Feb, 2018

1 commit

  • In kcm_attach strp_done is called when sk_user_data is already
    set to fail the attach. strp_done needs the strp to be stopped and
    warns if it isn't. Call strp_stop in this case to eliminate the
    warning message.

    Reported-by: syzbot+88dfb55e4c8b770d86e3@syzkaller.appspotmail.com
    Fixes: e5571240236c5652f ("kcm: Check if sk_user_data already set in kcm_attach"
    Signed-off-by: Tom Herbert
    Signed-off-by: David S. Miller

    Tom Herbert
     

12 Feb, 2018

1 commit

  • This is the mindless scripted replacement of kernel use of POLL*
    variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
    L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
    for f in $L; do sed -i "-es/^\([^\"]*\)\(\\)/\\1E\\2/" $f; done
    done

    with de-mangling cleanups yet to come.

    NOTE! On almost all architectures, the EPOLL* constants have the same
    values as the POLL* constants do. But they keyword here is "almost".
    For various bad reasons they aren't the same, and epoll() doesn't
    actually work quite correctly in some cases due to this on Sparc et al.

    The next patch from Al will sort out the final differences, and we
    should be all done.

    Scripted-by: Al Viro
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

25 Jan, 2018

2 commits

  • This is needed to prevent sk_user_data being overwritten.
    The check is done under the callback lock. This should prevent
    a socket from being attached twice to a KCM mux. It also prevents
    a socket from being attached for other use cases of sk_user_data
    as long as the other cases set sk_user_data under the lock.
    Followup work is needed to unify all the use cases of sk_user_data
    to use the same locking.

    Reported-by: syzbot+114b15f2be420a8886c3@syzkaller.appspotmail.com
    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Signed-off-by: Tom Herbert
    Reviewed-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Tom Herbert
     
  • TCP sockets for IPv4 and IPv6 that are not listeners or in closed
    stated are allowed to be attached to a KCM mux.

    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Reported-by: syzbot+8865eaff7f9acd593945@syzkaller.appspotmail.com
    Signed-off-by: Tom Herbert
    Reviewed-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Tom Herbert
     

06 Dec, 2017

2 commits

  • This changes calling conventions (and simplifies the hell out
    the callers). New rules: once struct socket had been passed
    to sock_alloc_file(), it's been consumed either by struct file
    or by sock_release() done by sock_alloc_file(). Either way
    the caller should not do sock_release() after that point.

    Reviewed-by: Eric Dumazet
    Signed-off-by: Al Viro
    Signed-off-by: David S. Miller

    Al Viro
     
  • 1) it's fput() or sock_release(), not both
    2) don't do fd_install() until the last failure exit.
    3) not a bug per se, but... don't attach socket to struct file
    until it's set up.

    Take reserving descriptor into the caller, move fd_install() to the
    caller, sanitize failure exits and calling conventions.

    Cc: stable@vger.kernel.org # v4.6+
    Acked-by: Tom Herbert
    Signed-off-by: Al Viro
    Signed-off-by: David S. Miller

    Al Viro
     

27 Sep, 2017

1 commit


02 Sep, 2017

1 commit


31 Aug, 2017

1 commit

  • syzkaller had no problem to trigger a deadlock, attaching a KCM socket
    to another one (or itself). (original syzkaller report was a very
    confusing lockdep splat during a sendmsg())

    It seems KCM claims to only support TCP, but no enforcement is done,
    so we might need to add additional checks.

    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Signed-off-by: Eric Dumazet
    Reported-by: Dmitry Vyukov
    Acked-by: Tom Herbert
    Signed-off-by: David S. Miller

    Eric Dumazet
     

25 Aug, 2017

1 commit

  • commit bbb03029a899 ("strparser: Generalize strparser") added more
    function pointers to 'struct strp_callbacks'; however, kcm_attach() was
    not updated to initialize them. This could cause the ->lock() and/or
    ->unlock() function pointers to be set to garbage values, causing a
    crash in strp_work().

    Fix the bug by moving the callback structs into static memory, so
    unspecified members are zeroed. Also constify them while we're at it.

    This bug was found by syzkaller, which encountered the following splat:

    IP: 0x55
    PGD 3b1ca067
    P4D 3b1ca067
    PUD 3b12f067
    PMD 0

    Oops: 0010 [#1] SMP KASAN
    Dumping ftrace buffer:
    (ftrace buffer empty)
    Modules linked in:
    CPU: 2 PID: 1194 Comm: kworker/u8:1 Not tainted 4.13.0-rc4-next-20170811 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Workqueue: kstrp strp_work
    task: ffff88006bb0e480 task.stack: ffff88006bb10000
    RIP: 0010:0x55
    RSP: 0018:ffff88006bb17540 EFLAGS: 00010246
    RAX: dffffc0000000000 RBX: ffff88006ce4bd60 RCX: 0000000000000000
    RDX: 1ffff1000d9c97bd RSI: 0000000000000000 RDI: ffff88006ce4bc48
    RBP: ffff88006bb17558 R08: ffffffff81467ab2 R09: 0000000000000000
    R10: ffff88006bb17438 R11: ffff88006bb17940 R12: ffff88006ce4bc48
    R13: ffff88003c683018 R14: ffff88006bb17980 R15: ffff88003c683000
    FS: 0000000000000000(0000) GS:ffff88006de00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000055 CR3: 000000003c145000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    process_one_work+0xbf3/0x1bc0 kernel/workqueue.c:2098
    worker_thread+0x223/0x1860 kernel/workqueue.c:2233
    kthread+0x35e/0x430 kernel/kthread.c:231
    ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
    Code: Bad RIP value.
    RIP: 0x55 RSP: ffff88006bb17540
    CR2: 0000000000000055
    ---[ end trace f0e4920047069cee ]---

    Here is a C reproducer (requires CONFIG_BPF_SYSCALL=y and
    CONFIG_AF_KCM=y):

    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    static const struct bpf_insn bpf_insns[3] = {
    { .code = 0xb7 }, /* BPF_MOV64_IMM(0, 0) */
    { .code = 0x95 }, /* BPF_EXIT_INSN() */
    };

    static const union bpf_attr bpf_attr = {
    .prog_type = 1,
    .insn_cnt = 2,
    .insns = (uintptr_t)&bpf_insns,
    .license = (uintptr_t)"",
    };

    int main(void)
    {
    int bpf_fd = syscall(__NR_bpf, BPF_PROG_LOAD,
    &bpf_attr, sizeof(bpf_attr));
    int inet_fd = socket(AF_INET, SOCK_STREAM, 0);
    int kcm_fd = socket(AF_KCM, SOCK_DGRAM, 0);

    ioctl(kcm_fd, SIOCKCMATTACH,
    &(struct kcm_attach) { .fd = inet_fd, .bpf_fd = bpf_fd });
    }

    Fixes: bbb03029a899 ("strparser: Generalize strparser")
    Cc: Dmitry Vyukov
    Cc: Tom Herbert
    Signed-off-by: Eric Biggers
    Signed-off-by: David S. Miller

    Eric Biggers
     

02 Aug, 2017

1 commit

  • Generalize strparser from more than just being used in conjunction
    with read_sock. strparser will also be used in the send path with
    zero proxy. The primary change is to create strp_process function
    that performs the critical processing on skbs. The documentation
    is also updated to reflect the new uses.

    Signed-off-by: Tom Herbert
    Signed-off-by: David S. Miller

    Tom Herbert
     

16 May, 2017

1 commit


18 Apr, 2017

1 commit


25 Mar, 2017

1 commit


02 Mar, 2017

1 commit


15 Feb, 2017

1 commit

  • In commit 98e3862ca2b1 ("kcm: fix 0-length case for kcm_sendmsg()")
    I tried to avoid skb allocation for 0-length case, but missed
    a check for NULL pointer in the non EOR case.

    Fixes: 98e3862ca2b1 ("kcm: fix 0-length case for kcm_sendmsg()")
    Reported-by: Dmitry Vyukov
    Cc: Tom Herbert
    Signed-off-by: Cong Wang
    Acked-by: Tom Herbert
    Signed-off-by: David S. Miller

    WANG Cong
     

10 Feb, 2017

1 commit

  • Dmitry reported a kernel warning:

    WARNING: CPU: 3 PID: 2936 at net/kcm/kcmsock.c:627
    kcm_write_msgs+0x12e3/0x1b90 net/kcm/kcmsock.c:627
    CPU: 3 PID: 2936 Comm: a.out Not tainted 4.10.0-rc6+ #209
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Call Trace:
    __dump_stack lib/dump_stack.c:15 [inline]
    dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
    panic+0x1fb/0x412 kernel/panic.c:179
    __warn+0x1c4/0x1e0 kernel/panic.c:539
    warn_slowpath_null+0x2c/0x40 kernel/panic.c:582
    kcm_write_msgs+0x12e3/0x1b90 net/kcm/kcmsock.c:627
    kcm_sendmsg+0x163a/0x2200 net/kcm/kcmsock.c:1029
    sock_sendmsg_nosec net/socket.c:635 [inline]
    sock_sendmsg+0xca/0x110 net/socket.c:645
    sock_write_iter+0x326/0x600 net/socket.c:848
    new_sync_write fs/read_write.c:499 [inline]
    __vfs_write+0x483/0x740 fs/read_write.c:512
    vfs_write+0x187/0x530 fs/read_write.c:560
    SYSC_write fs/read_write.c:607 [inline]
    SyS_write+0xfb/0x230 fs/read_write.c:599
    entry_SYSCALL_64_fastpath+0x1f/0xc2

    when calling syscall(__NR_write, sock2, 0x208aaf27ul, 0x0ul) on a KCM
    seqpacket socket. It appears that kcm_sendmsg() does not handle len==0
    case correctly, which causes an empty skb is allocated and queued.
    Fix this by skipping the skb allocation for len==0 case.

    Reported-by: Dmitry Vyukov
    Cc: Tom Herbert
    Signed-off-by: Cong Wang
    Signed-off-by: David S. Miller

    WANG Cong
     

08 Oct, 2016

1 commit

  • Pull VFS splice updates from Al Viro:
    "There's a bunch of branches this cycle, both mine and from other folks
    and I'd rather send pull requests separately.

    This one is the conversion of ->splice_read() to ITER_PIPE iov_iter
    (and introduction of such). Gets rid of a lot of code in fs/splice.c
    and elsewhere; there will be followups, but these are for the next
    cycle... Some pipe/splice-related cleanups from Miklos in the same
    branch as well"

    * 'work.splice_read' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    pipe: fix comment in pipe_buf_operations
    pipe: add pipe_buf_steal() helper
    pipe: add pipe_buf_confirm() helper
    pipe: add pipe_buf_release() helper
    pipe: add pipe_buf_get() helper
    relay: simplify relay_file_read()
    switch default_file_splice_read() to use of pipe-backed iov_iter
    switch generic_file_splice_read() to use of ->read_iter()
    new iov_iter flavour: pipe-backed
    fuse_dev_splice_read(): switch to add_to_pipe()
    skb_splice_bits(): get rid of callback
    new helper: add_to_pipe()
    splice: lift pipe_lock out of splice_to_pipe()
    splice: switch get_iovec_page_array() to iov_iter
    splice_to_pipe(): don't open-code wakeup_pipe_readers()
    consistent treatment of EFAULT on O_DIRECT read/write

    Linus Torvalds
     

04 Oct, 2016

1 commit

  • since pipe_lock is the outermost now, we don't need to drop/regain
    socket locks around the call of splice_to_pipe() from skb_splice_bits(),
    which kills the need to have a socket-specific callback; we can just
    call splice_to_pipe() and be done with that.

    Signed-off-by: Al Viro

    Al Viro
     

13 Sep, 2016

1 commit


01 Sep, 2016

1 commit

  • Dmitry reported a double free on kcm socket, which could
    be easily reproduced by:

    #include
    #include

    int main()
    {
    int fd = syscall(SYS_socket, 0x29ul, 0x5ul, 0x0ul, 0, 0, 0);
    syscall(SYS_ioctl, fd, 0x89e2ul, 0x20a98000ul, 0, 0, 0);
    return 0;
    }

    This is because on the error path, after we install
    the new socket file, we call sock_release() to clean
    up the socket, which leaves the fd pointing to a freed
    socket. Fix this by calling sys_close() on that fd
    directly.

    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Reported-by: Dmitry Vyukov
    Cc: Tom Herbert
    Signed-off-by: Cong Wang
    Signed-off-by: David S. Miller

    WANG Cong
     

29 Aug, 2016

1 commit