All of lore.kernel.org
 help / color / mirror / Atom feed
* use-after-free in inet6_destroy_sock
@ 2015-12-09 14:15 ` Dmitry Vyukov
  0 siblings, 0 replies; 34+ messages in thread
From: Dmitry Vyukov @ 2015-12-09 14:15 UTC (permalink / raw)
  To: David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, Eric Dumazet
  Cc: syzkaller, Kostya Serebryany, Alexander Potapenko, Sasha Levin

Hello,

The following program causes use-after-free in inet6_destroy_sock:

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <syscall.h>
#include <string.h>
#include <stdint.h>
#include <pthread.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <linux/in.h>
#include <linux/in6.h>

int cfd = -1;

void *thr(void *arg)
{
        cfd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
        struct sockaddr_in6 sa = {};
        sa.sin6_family = AF_INET6;
        sa.sin6_port = getpid();
        sa.sin6_addr.s6_addr[15] = 1;
        syscall(SYS_connect, cfd, &sa, sizeof(sa), 0, 0, 0);
        return 0;
}

int main()
{
        syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul,
0xfffffffffffffffful, 0x0ul);
        int fd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
        struct sockaddr_in6 sa = {};
        sa.sin6_family = AF_INET6;
        sa.sin6_port = getpid();
        sa.sin6_addr.s6_addr[15] = 1;
        syscall(SYS_bind, fd, &sa, sizeof(sa), 0, 0, 0);
        syscall(SYS_listen, fd, 0x3ul, 0, 0, 0, 0);
        memcpy((void*)0x20002ff6,
"\x10\x48\xe0\xad\x68\xc0\xce\x4c\xd0\xb5", 10);
        syscall(SYS_setsockopt, fd, 0x29ul, 0x6ul, 0x20002ff6ul, 0xaul, 0);
        pthread_t th;
        pthread_create(&th, 0, thr, 0);
        pthread_join(th, 0);
        int sfd = syscall(SYS_accept4, fd, 0x20003f80ul, 0x20003ab4ul,
0x80800ul, 0, 0);
        dup3(fd, -1, 0x80000);
        return 0;
}


==================================================================
BUG: KASAN: use-after-free in inet6_destroy_sock+0x177/0x1c0 at addr
ffff8800349179b4
Read of size 4 by task executor/7001
=============================================================================
BUG kmalloc-96 (Not tainted): kasan: bad access detected
-----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Allocated in sock_kmalloc+0x93/0x100 age=20 cpu=0 pid=7064
[<      none      >] ___slab_alloc+0x648/0x8c0 mm/slub.c:2468
[<      none      >] __slab_alloc+0x4c/0x90 mm/slub.c:2497
[<     inline     >] slab_alloc_node mm/slub.c:2560
[<     inline     >] slab_alloc mm/slub.c:2602
[<      none      >] __kmalloc+0x2d9/0x480 mm/slub.c:3562
[<     inline     >] kmalloc include/linux/slab.h:463
[<      none      >] sock_kmalloc+0x93/0x100 net/core/sock.c:1771
[<      none      >] do_ipv6_setsockopt.isra.5+0x1f43/0x2e50
net/ipv6/ipv6_sockglue.c:490
[<      none      >] ipv6_setsockopt+0x4f/0x150 net/ipv6/ipv6_sockglue.c:895
[<      none      >] sctp_setsockopt+0x194/0x4020 net/sctp/socket.c:3702
[<      none      >] sock_common_setsockopt+0xb4/0x140 net/core/sock.c:2641
[<     inline     >] SYSC_setsockopt net/socket.c:1750
[<      none      >] SyS_setsockopt+0x161/0x290 net/socket.c:1729
[<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185

INFO: Freed in rcu_process_callbacks+0x52c/0x19e0 age=16 cpu=0 pid=0
[<      none      >] __slab_free+0x21e/0x3e0 mm/slub.c:2678
[<     inline     >] slab_free mm/slub.c:2833
[<      none      >] kfree+0x26f/0x3e0 mm/slub.c:3662
[<     inline     >] __rcu_reclaim kernel/rcu/rcu.h:113
[<     inline     >] rcu_do_batch kernel/rcu/tree.c:2693
[<     inline     >] invoke_rcu_callbacks kernel/rcu/tree.c:2961
[<     inline     >] __rcu_process_callbacks kernel/rcu/tree.c:2928
[<      none      >] rcu_process_callbacks+0x52c/0x19e0 kernel/rcu/tree.c:2945
[<      none      >] __do_softirq+0x2e5/0xb40 kernel/softirq.c:273
[<     inline     >] invoke_softirq kernel/softirq.c:350
[<      none      >] irq_exit+0x165/0x1e0 kernel/softirq.c:391
[<     inline     >] exiting_irq ./arch/x86/include/asm/apic.h:653
[<      none      >] smp_apic_timer_interrupt+0x88/0xc0
arch/x86/kernel/apic/apic.c:926
[<      none      >] apic_timer_interrupt+0x8c/0xa0
arch/x86/entry/entry_64.S:520
[<     inline     >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:111
[<      none      >] default_idle+0x22/0x300 arch/x86/kernel/process.c:304
[<      none      >] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:295
[<      none      >] default_idle_call+0x4f/0x80 kernel/sched/idle.c:92
[<     inline     >] cpuidle_idle_call kernel/sched/idle.c:156
[<     inline     >] cpu_idle_loop kernel/sched/idle.c:251
[<      none      >] cpu_startup_entry+0x481/0x690 kernel/sched/idle.c:299
[<      none      >] rest_init+0x1c7/0x1d0 init/main.c:412
[<      none      >] start_kernel+0x6cd/0x6f3 init/main.c:683
[<      none      >] x86_64_start_reservations+0x2a/0x2c
arch/x86/kernel/head64.c:195
[<      none      >] x86_64_start_kernel+0x176/0x185
arch/x86/kernel/head64.c:184

INFO: Slab 0xffffea0000d24500 objects=28 used=26 fp=0xffff8800349179b0
flags=0x1fffc0000004080
INFO: Object 0xffff8800349179b0 @offset=14768 fp=0xffff880034914000
CPU: 1 PID: 7001 Comm: executor Tainted: G    B           4.4.0-rc4+ #158
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 0000000000000001 ffff880062eef940 ffffffff82e0f6d8 0000000041b58ab3
 ffffffff87aa2c7d ffffffff82e0f626 ffff88006c051740 ffffffff87ac3e19
 ffff88003e804900 0000000000000008 ffff8800349179b0 ffff880062eef940

Call Trace:
 [<ffffffff818450f4>] __asan_report_load4_noabort+0x54/0x70
mm/kasan/report.c:294
 [<ffffffff85d61f17>] inet6_destroy_sock+0x177/0x1c0 net/ipv6/af_inet6.c:433
 [<ffffffff864df89d>] sctp_v6_destroy_sock+0x1d/0x20 net/sctp/socket.c:7389
 [<ffffffff856cf00d>] sk_common_release+0x7d/0x3e0 net/core/sock.c:2662
 [<ffffffff864e58fe>] sctp_close+0x5fe/0x9b0 net/sctp/socket.c:1541
 [<ffffffff85bfe691>] inet_release+0x111/0x270 net/ipv4/af_inet.c:413
 [<ffffffff85d60ce5>] inet6_release+0x55/0x90 net/ipv6/af_inet6.c:406
 [<ffffffff856b3b96>] sock_release+0x96/0x260 net/socket.c:571
 [<ffffffff856b3d76>] sock_close+0x16/0x20 net/socket.c:1022
 [<ffffffff8189d304>] __fput+0x244/0x860 fs/file_table.c:208
 [<ffffffff8189d9b5>] ____fput+0x15/0x20 fs/file_table.c:244
 [<ffffffff813e2dc0>] task_work_run+0x130/0x240 kernel/task_work.c:115
 [<     inline     >] exit_task_work include/linux/task_work.h:21
 [<ffffffff8137d1e5>] do_exit+0x885/0x3050 kernel/exit.c:750
 [<ffffffff8137fb0c>] do_group_exit+0xec/0x390 kernel/exit.c:880
 [<     inline     >] SYSC_exit_group kernel/exit.c:891
 [<ffffffff8137fdcd>] SyS_exit_group+0x1d/0x20 kernel/exit.c:889
 [<ffffffff86a924f6>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
==================================================================

On commit aa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85 (Nov 8).
Eric, this now includes your patches that you previously pointed me
to, and also https://patchwork.ozlabs.org/patch/553068/ on top of it.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* use-after-free in inet6_destroy_sock
@ 2015-12-09 14:15 ` Dmitry Vyukov
  0 siblings, 0 replies; 34+ messages in thread
From: Dmitry Vyukov @ 2015-12-09 14:15 UTC (permalink / raw)
  To: David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, Eric Dumazet
  Cc: syzkaller, Kostya Serebryany, Alexander Potapenko, Sasha Levin

Hello,

The following program causes use-after-free in inet6_destroy_sock:

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <syscall.h>
#include <string.h>
#include <stdint.h>
#include <pthread.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <linux/in.h>
#include <linux/in6.h>

int cfd = -1;

void *thr(void *arg)
{
        cfd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
        struct sockaddr_in6 sa = {};
        sa.sin6_family = AF_INET6;
        sa.sin6_port = getpid();
        sa.sin6_addr.s6_addr[15] = 1;
        syscall(SYS_connect, cfd, &sa, sizeof(sa), 0, 0, 0);
        return 0;
}

int main()
{
        syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul,
0xfffffffffffffffful, 0x0ul);
        int fd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
        struct sockaddr_in6 sa = {};
        sa.sin6_family = AF_INET6;
        sa.sin6_port = getpid();
        sa.sin6_addr.s6_addr[15] = 1;
        syscall(SYS_bind, fd, &sa, sizeof(sa), 0, 0, 0);
        syscall(SYS_listen, fd, 0x3ul, 0, 0, 0, 0);
        memcpy((void*)0x20002ff6,
"\x10\x48\xe0\xad\x68\xc0\xce\x4c\xd0\xb5", 10);
        syscall(SYS_setsockopt, fd, 0x29ul, 0x6ul, 0x20002ff6ul, 0xaul, 0);
        pthread_t th;
        pthread_create(&th, 0, thr, 0);
        pthread_join(th, 0);
        int sfd = syscall(SYS_accept4, fd, 0x20003f80ul, 0x20003ab4ul,
0x80800ul, 0, 0);
        dup3(fd, -1, 0x80000);
        return 0;
}


=================================
BUG: KASAN: use-after-free in inet6_destroy_sock+0x177/0x1c0 at addr
ffff8800349179b4
Read of size 4 by task executor/7001
======================================BUG kmalloc-96 (Not tainted): kasan: bad access detected
-----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Allocated in sock_kmalloc+0x93/0x100 age  cpu=0 pidp64
[<      none      >] ___slab_alloc+0x648/0x8c0 mm/slub.c:2468
[<      none      >] __slab_alloc+0x4c/0x90 mm/slub.c:2497
[<     inline     >] slab_alloc_node mm/slub.c:2560
[<     inline     >] slab_alloc mm/slub.c:2602
[<      none      >] __kmalloc+0x2d9/0x480 mm/slub.c:3562
[<     inline     >] kmalloc include/linux/slab.h:463
[<      none      >] sock_kmalloc+0x93/0x100 net/core/sock.c:1771
[<      none      >] do_ipv6_setsockopt.isra.5+0x1f43/0x2e50
net/ipv6/ipv6_sockglue.c:490
[<      none      >] ipv6_setsockopt+0x4f/0x150 net/ipv6/ipv6_sockglue.c:895
[<      none      >] sctp_setsockopt+0x194/0x4020 net/sctp/socket.c:3702
[<      none      >] sock_common_setsockopt+0xb4/0x140 net/core/sock.c:2641
[<     inline     >] SYSC_setsockopt net/socket.c:1750
[<      none      >] SyS_setsockopt+0x161/0x290 net/socket.c:1729
[<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185

INFO: Freed in rcu_process_callbacks+0x52c/0x19e0 age\x16 cpu=0 pid=0
[<      none      >] __slab_free+0x21e/0x3e0 mm/slub.c:2678
[<     inline     >] slab_free mm/slub.c:2833
[<      none      >] kfree+0x26f/0x3e0 mm/slub.c:3662
[<     inline     >] __rcu_reclaim kernel/rcu/rcu.h:113
[<     inline     >] rcu_do_batch kernel/rcu/tree.c:2693
[<     inline     >] invoke_rcu_callbacks kernel/rcu/tree.c:2961
[<     inline     >] __rcu_process_callbacks kernel/rcu/tree.c:2928
[<      none      >] rcu_process_callbacks+0x52c/0x19e0 kernel/rcu/tree.c:2945
[<      none      >] __do_softirq+0x2e5/0xb40 kernel/softirq.c:273
[<     inline     >] invoke_softirq kernel/softirq.c:350
[<      none      >] irq_exit+0x165/0x1e0 kernel/softirq.c:391
[<     inline     >] exiting_irq ./arch/x86/include/asm/apic.h:653
[<      none      >] smp_apic_timer_interrupt+0x88/0xc0
arch/x86/kernel/apic/apic.c:926
[<      none      >] apic_timer_interrupt+0x8c/0xa0
arch/x86/entry/entry_64.S:520
[<     inline     >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:111
[<      none      >] default_idle+0x22/0x300 arch/x86/kernel/process.c:304
[<      none      >] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:295
[<      none      >] default_idle_call+0x4f/0x80 kernel/sched/idle.c:92
[<     inline     >] cpuidle_idle_call kernel/sched/idle.c:156
[<     inline     >] cpu_idle_loop kernel/sched/idle.c:251
[<      none      >] cpu_startup_entry+0x481/0x690 kernel/sched/idle.c:299
[<      none      >] rest_init+0x1c7/0x1d0 init/main.c:412
[<      none      >] start_kernel+0x6cd/0x6f3 init/main.c:683
[<      none      >] x86_64_start_reservations+0x2a/0x2c
arch/x86/kernel/head64.c:195
[<      none      >] x86_64_start_kernel+0x176/0x185
arch/x86/kernel/head64.c:184

INFO: Slab 0xffffea0000d24500 objects( used& fp=0xffff8800349179b0
flags=0x1fffc0000004080
INFO: Object 0xffff8800349179b0 @offset\x14768 fp=0xffff880034914000
CPU: 1 PID: 7001 Comm: executor Tainted: G    B           4.4.0-rc4+ #158
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 0000000000000001 ffff880062eef940 ffffffff82e0f6d8 0000000041b58ab3
 ffffffff87aa2c7d ffffffff82e0f626 ffff88006c051740 ffffffff87ac3e19
 ffff88003e804900 0000000000000008 ffff8800349179b0 ffff880062eef940

Call Trace:
 [<ffffffff818450f4>] __asan_report_load4_noabort+0x54/0x70
mm/kasan/report.c:294
 [<ffffffff85d61f17>] inet6_destroy_sock+0x177/0x1c0 net/ipv6/af_inet6.c:433
 [<ffffffff864df89d>] sctp_v6_destroy_sock+0x1d/0x20 net/sctp/socket.c:7389
 [<ffffffff856cf00d>] sk_common_release+0x7d/0x3e0 net/core/sock.c:2662
 [<ffffffff864e58fe>] sctp_close+0x5fe/0x9b0 net/sctp/socket.c:1541
 [<ffffffff85bfe691>] inet_release+0x111/0x270 net/ipv4/af_inet.c:413
 [<ffffffff85d60ce5>] inet6_release+0x55/0x90 net/ipv6/af_inet6.c:406
 [<ffffffff856b3b96>] sock_release+0x96/0x260 net/socket.c:571
 [<ffffffff856b3d76>] sock_close+0x16/0x20 net/socket.c:1022
 [<ffffffff8189d304>] __fput+0x244/0x860 fs/file_table.c:208
 [<ffffffff8189d9b5>] ____fput+0x15/0x20 fs/file_table.c:244
 [<ffffffff813e2dc0>] task_work_run+0x130/0x240 kernel/task_work.c:115
 [<     inline     >] exit_task_work include/linux/task_work.h:21
 [<ffffffff8137d1e5>] do_exit+0x885/0x3050 kernel/exit.c:750
 [<ffffffff8137fb0c>] do_group_exit+0xec/0x390 kernel/exit.c:880
 [<     inline     >] SYSC_exit_group kernel/exit.c:891
 [<ffffffff8137fdcd>] SyS_exit_group+0x1d/0x20 kernel/exit.c:889
 [<ffffffff86a924f6>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
=================================

On commit aa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85 (Nov 8).
Eric, this now includes your patches that you previously pointed me
to, and also https://patchwork.ozlabs.org/patch/553068/ on top of it.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: use-after-free in inet6_destroy_sock
  2015-12-09 14:15 ` Dmitry Vyukov
@ 2015-12-09 14:43   ` Eric Dumazet
  -1 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-09 14:43 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Wed, Dec 9, 2015 at 6:15 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> The following program causes use-after-free in inet6_destroy_sock:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <syscall.h>
> #include <string.h>
> #include <stdint.h>
> #include <pthread.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <linux/in.h>
> #include <linux/in6.h>
>
> int cfd = -1;
>
> void *thr(void *arg)
> {
>         cfd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
>         struct sockaddr_in6 sa = {};
>         sa.sin6_family = AF_INET6;
>         sa.sin6_port = getpid();
>         sa.sin6_addr.s6_addr[15] = 1;
>         syscall(SYS_connect, cfd, &sa, sizeof(sa), 0, 0, 0);
>         return 0;
> }
>
> int main()
> {
>         syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul,
> 0xfffffffffffffffful, 0x0ul);
>         int fd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
>         struct sockaddr_in6 sa = {};
>         sa.sin6_family = AF_INET6;
>         sa.sin6_port = getpid();
>         sa.sin6_addr.s6_addr[15] = 1;
>         syscall(SYS_bind, fd, &sa, sizeof(sa), 0, 0, 0);
>         syscall(SYS_listen, fd, 0x3ul, 0, 0, 0, 0);
>         memcpy((void*)0x20002ff6,
> "\x10\x48\xe0\xad\x68\xc0\xce\x4c\xd0\xb5", 10);
>         syscall(SYS_setsockopt, fd, 0x29ul, 0x6ul, 0x20002ff6ul, 0xaul, 0);
>         pthread_t th;
>         pthread_create(&th, 0, thr, 0);
>         pthread_join(th, 0);
>         int sfd = syscall(SYS_accept4, fd, 0x20003f80ul, 0x20003ab4ul,
> 0x80800ul, 0, 0);
>         dup3(fd, -1, 0x80000);
>         return 0;
> }
>
>
> ==================================================================
> BUG: KASAN: use-after-free in inet6_destroy_sock+0x177/0x1c0 at addr
> ffff8800349179b4
> Read of size 4 by task executor/7001
> =============================================================================
> BUG kmalloc-96 (Not tainted): kasan: bad access detected
> -----------------------------------------------------------------------------
>
> Disabling lock debugging due to kernel taint
> INFO: Allocated in sock_kmalloc+0x93/0x100 age=20 cpu=0 pid=7064
> [<      none      >] ___slab_alloc+0x648/0x8c0 mm/slub.c:2468
> [<      none      >] __slab_alloc+0x4c/0x90 mm/slub.c:2497
> [<     inline     >] slab_alloc_node mm/slub.c:2560
> [<     inline     >] slab_alloc mm/slub.c:2602
> [<      none      >] __kmalloc+0x2d9/0x480 mm/slub.c:3562
> [<     inline     >] kmalloc include/linux/slab.h:463
> [<      none      >] sock_kmalloc+0x93/0x100 net/core/sock.c:1771
> [<      none      >] do_ipv6_setsockopt.isra.5+0x1f43/0x2e50
> net/ipv6/ipv6_sockglue.c:490
> [<      none      >] ipv6_setsockopt+0x4f/0x150 net/ipv6/ipv6_sockglue.c:895
> [<      none      >] sctp_setsockopt+0x194/0x4020 net/sctp/socket.c:3702
> [<      none      >] sock_common_setsockopt+0xb4/0x140 net/core/sock.c:2641
> [<     inline     >] SYSC_setsockopt net/socket.c:1750
> [<      none      >] SyS_setsockopt+0x161/0x290 net/socket.c:1729
> [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
>
> INFO: Freed in rcu_process_callbacks+0x52c/0x19e0 age=16 cpu=0 pid=0
> [<      none      >] __slab_free+0x21e/0x3e0 mm/slub.c:2678
> [<     inline     >] slab_free mm/slub.c:2833
> [<      none      >] kfree+0x26f/0x3e0 mm/slub.c:3662
> [<     inline     >] __rcu_reclaim kernel/rcu/rcu.h:113
> [<     inline     >] rcu_do_batch kernel/rcu/tree.c:2693
> [<     inline     >] invoke_rcu_callbacks kernel/rcu/tree.c:2961
> [<     inline     >] __rcu_process_callbacks kernel/rcu/tree.c:2928
> [<      none      >] rcu_process_callbacks+0x52c/0x19e0 kernel/rcu/tree.c:2945
> [<      none      >] __do_softirq+0x2e5/0xb40 kernel/softirq.c:273
> [<     inline     >] invoke_softirq kernel/softirq.c:350
> [<      none      >] irq_exit+0x165/0x1e0 kernel/softirq.c:391
> [<     inline     >] exiting_irq ./arch/x86/include/asm/apic.h:653
> [<      none      >] smp_apic_timer_interrupt+0x88/0xc0
> arch/x86/kernel/apic/apic.c:926
> [<      none      >] apic_timer_interrupt+0x8c/0xa0
> arch/x86/entry/entry_64.S:520
> [<     inline     >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:111
> [<      none      >] default_idle+0x22/0x300 arch/x86/kernel/process.c:304
> [<      none      >] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:295
> [<      none      >] default_idle_call+0x4f/0x80 kernel/sched/idle.c:92
> [<     inline     >] cpuidle_idle_call kernel/sched/idle.c:156
> [<     inline     >] cpu_idle_loop kernel/sched/idle.c:251
> [<      none      >] cpu_startup_entry+0x481/0x690 kernel/sched/idle.c:299
> [<      none      >] rest_init+0x1c7/0x1d0 init/main.c:412
> [<      none      >] start_kernel+0x6cd/0x6f3 init/main.c:683
> [<      none      >] x86_64_start_reservations+0x2a/0x2c
> arch/x86/kernel/head64.c:195
> [<      none      >] x86_64_start_kernel+0x176/0x185
> arch/x86/kernel/head64.c:184
>
> INFO: Slab 0xffffea0000d24500 objects=28 used=26 fp=0xffff8800349179b0
> flags=0x1fffc0000004080
> INFO: Object 0xffff8800349179b0 @offset=14768 fp=0xffff880034914000
> CPU: 1 PID: 7001 Comm: executor Tainted: G    B           4.4.0-rc4+ #158
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  0000000000000001 ffff880062eef940 ffffffff82e0f6d8 0000000041b58ab3
>  ffffffff87aa2c7d ffffffff82e0f626 ffff88006c051740 ffffffff87ac3e19
>  ffff88003e804900 0000000000000008 ffff8800349179b0 ffff880062eef940
>
> Call Trace:
>  [<ffffffff818450f4>] __asan_report_load4_noabort+0x54/0x70
> mm/kasan/report.c:294
>  [<ffffffff85d61f17>] inet6_destroy_sock+0x177/0x1c0 net/ipv6/af_inet6.c:433
>  [<ffffffff864df89d>] sctp_v6_destroy_sock+0x1d/0x20 net/sctp/socket.c:7389
>  [<ffffffff856cf00d>] sk_common_release+0x7d/0x3e0 net/core/sock.c:2662
>  [<ffffffff864e58fe>] sctp_close+0x5fe/0x9b0 net/sctp/socket.c:1541
>  [<ffffffff85bfe691>] inet_release+0x111/0x270 net/ipv4/af_inet.c:413
>  [<ffffffff85d60ce5>] inet6_release+0x55/0x90 net/ipv6/af_inet6.c:406
>  [<ffffffff856b3b96>] sock_release+0x96/0x260 net/socket.c:571
>  [<ffffffff856b3d76>] sock_close+0x16/0x20 net/socket.c:1022
>  [<ffffffff8189d304>] __fput+0x244/0x860 fs/file_table.c:208
>  [<ffffffff8189d9b5>] ____fput+0x15/0x20 fs/file_table.c:244
>  [<ffffffff813e2dc0>] task_work_run+0x130/0x240 kernel/task_work.c:115
>  [<     inline     >] exit_task_work include/linux/task_work.h:21
>  [<ffffffff8137d1e5>] do_exit+0x885/0x3050 kernel/exit.c:750
>  [<ffffffff8137fb0c>] do_group_exit+0xec/0x390 kernel/exit.c:880
>  [<     inline     >] SYSC_exit_group kernel/exit.c:891
>  [<ffffffff8137fdcd>] SyS_exit_group+0x1d/0x20 kernel/exit.c:889
>  [<ffffffff86a924f6>] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> ==================================================================
>
> On commit aa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85 (Nov 8).
> Eric, this now includes your patches that you previously pointed me
> to, and also https://patchwork.ozlabs.org/patch/553068/ on top of it.

Sure, I believe SCTP crowd already know they are missing ipv6_dup_options()

$ git grep -n ipv6_dup_options
include/net/ipv6.h:300:struct ipv6_txoptions *ipv6_dup_options(struct sock *sk,
net/dccp/ipv6.c:499:            opt = ipv6_dup_options(newsk, opt);
net/ipv6/exthdrs.c:714:ipv6_dup_options(struct sock *sk, struct
ipv6_txoptions *opt)
net/ipv6/exthdrs.c:734:EXPORT_SYMBOL_GPL(ipv6_dup_options);
net/ipv6/tcp_ipv6.c:1107:               opt = ipv6_dup_options(newsk, opt);

I can certainly send a patch, but maybe someone already cooked it and
is testing it ?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: use-after-free in inet6_destroy_sock
@ 2015-12-09 14:43   ` Eric Dumazet
  0 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-09 14:43 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Wed, Dec 9, 2015 at 6:15 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> The following program causes use-after-free in inet6_destroy_sock:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <syscall.h>
> #include <string.h>
> #include <stdint.h>
> #include <pthread.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <linux/in.h>
> #include <linux/in6.h>
>
> int cfd = -1;
>
> void *thr(void *arg)
> {
>         cfd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
>         struct sockaddr_in6 sa = {};
>         sa.sin6_family = AF_INET6;
>         sa.sin6_port = getpid();
>         sa.sin6_addr.s6_addr[15] = 1;
>         syscall(SYS_connect, cfd, &sa, sizeof(sa), 0, 0, 0);
>         return 0;
> }
>
> int main()
> {
>         syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul,
> 0xfffffffffffffffful, 0x0ul);
>         int fd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
>         struct sockaddr_in6 sa = {};
>         sa.sin6_family = AF_INET6;
>         sa.sin6_port = getpid();
>         sa.sin6_addr.s6_addr[15] = 1;
>         syscall(SYS_bind, fd, &sa, sizeof(sa), 0, 0, 0);
>         syscall(SYS_listen, fd, 0x3ul, 0, 0, 0, 0);
>         memcpy((void*)0x20002ff6,
> "\x10\x48\xe0\xad\x68\xc0\xce\x4c\xd0\xb5", 10);
>         syscall(SYS_setsockopt, fd, 0x29ul, 0x6ul, 0x20002ff6ul, 0xaul, 0);
>         pthread_t th;
>         pthread_create(&th, 0, thr, 0);
>         pthread_join(th, 0);
>         int sfd = syscall(SYS_accept4, fd, 0x20003f80ul, 0x20003ab4ul,
> 0x80800ul, 0, 0);
>         dup3(fd, -1, 0x80000);
>         return 0;
> }
>
>
> =================================
> BUG: KASAN: use-after-free in inet6_destroy_sock+0x177/0x1c0 at addr
> ffff8800349179b4
> Read of size 4 by task executor/7001
> ======================================> BUG kmalloc-96 (Not tainted): kasan: bad access detected
> -----------------------------------------------------------------------------
>
> Disabling lock debugging due to kernel taint
> INFO: Allocated in sock_kmalloc+0x93/0x100 age  cpu=0 pidp64
> [<      none      >] ___slab_alloc+0x648/0x8c0 mm/slub.c:2468
> [<      none      >] __slab_alloc+0x4c/0x90 mm/slub.c:2497
> [<     inline     >] slab_alloc_node mm/slub.c:2560
> [<     inline     >] slab_alloc mm/slub.c:2602
> [<      none      >] __kmalloc+0x2d9/0x480 mm/slub.c:3562
> [<     inline     >] kmalloc include/linux/slab.h:463
> [<      none      >] sock_kmalloc+0x93/0x100 net/core/sock.c:1771
> [<      none      >] do_ipv6_setsockopt.isra.5+0x1f43/0x2e50
> net/ipv6/ipv6_sockglue.c:490
> [<      none      >] ipv6_setsockopt+0x4f/0x150 net/ipv6/ipv6_sockglue.c:895
> [<      none      >] sctp_setsockopt+0x194/0x4020 net/sctp/socket.c:3702
> [<      none      >] sock_common_setsockopt+0xb4/0x140 net/core/sock.c:2641
> [<     inline     >] SYSC_setsockopt net/socket.c:1750
> [<      none      >] SyS_setsockopt+0x161/0x290 net/socket.c:1729
> [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
>
> INFO: Freed in rcu_process_callbacks+0x52c/0x19e0 age\x16 cpu=0 pid=0
> [<      none      >] __slab_free+0x21e/0x3e0 mm/slub.c:2678
> [<     inline     >] slab_free mm/slub.c:2833
> [<      none      >] kfree+0x26f/0x3e0 mm/slub.c:3662
> [<     inline     >] __rcu_reclaim kernel/rcu/rcu.h:113
> [<     inline     >] rcu_do_batch kernel/rcu/tree.c:2693
> [<     inline     >] invoke_rcu_callbacks kernel/rcu/tree.c:2961
> [<     inline     >] __rcu_process_callbacks kernel/rcu/tree.c:2928
> [<      none      >] rcu_process_callbacks+0x52c/0x19e0 kernel/rcu/tree.c:2945
> [<      none      >] __do_softirq+0x2e5/0xb40 kernel/softirq.c:273
> [<     inline     >] invoke_softirq kernel/softirq.c:350
> [<      none      >] irq_exit+0x165/0x1e0 kernel/softirq.c:391
> [<     inline     >] exiting_irq ./arch/x86/include/asm/apic.h:653
> [<      none      >] smp_apic_timer_interrupt+0x88/0xc0
> arch/x86/kernel/apic/apic.c:926
> [<      none      >] apic_timer_interrupt+0x8c/0xa0
> arch/x86/entry/entry_64.S:520
> [<     inline     >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:111
> [<      none      >] default_idle+0x22/0x300 arch/x86/kernel/process.c:304
> [<      none      >] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:295
> [<      none      >] default_idle_call+0x4f/0x80 kernel/sched/idle.c:92
> [<     inline     >] cpuidle_idle_call kernel/sched/idle.c:156
> [<     inline     >] cpu_idle_loop kernel/sched/idle.c:251
> [<      none      >] cpu_startup_entry+0x481/0x690 kernel/sched/idle.c:299
> [<      none      >] rest_init+0x1c7/0x1d0 init/main.c:412
> [<      none      >] start_kernel+0x6cd/0x6f3 init/main.c:683
> [<      none      >] x86_64_start_reservations+0x2a/0x2c
> arch/x86/kernel/head64.c:195
> [<      none      >] x86_64_start_kernel+0x176/0x185
> arch/x86/kernel/head64.c:184
>
> INFO: Slab 0xffffea0000d24500 objects( used& fp=0xffff8800349179b0
> flags=0x1fffc0000004080
> INFO: Object 0xffff8800349179b0 @offset\x14768 fp=0xffff880034914000
> CPU: 1 PID: 7001 Comm: executor Tainted: G    B           4.4.0-rc4+ #158
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  0000000000000001 ffff880062eef940 ffffffff82e0f6d8 0000000041b58ab3
>  ffffffff87aa2c7d ffffffff82e0f626 ffff88006c051740 ffffffff87ac3e19
>  ffff88003e804900 0000000000000008 ffff8800349179b0 ffff880062eef940
>
> Call Trace:
>  [<ffffffff818450f4>] __asan_report_load4_noabort+0x54/0x70
> mm/kasan/report.c:294
>  [<ffffffff85d61f17>] inet6_destroy_sock+0x177/0x1c0 net/ipv6/af_inet6.c:433
>  [<ffffffff864df89d>] sctp_v6_destroy_sock+0x1d/0x20 net/sctp/socket.c:7389
>  [<ffffffff856cf00d>] sk_common_release+0x7d/0x3e0 net/core/sock.c:2662
>  [<ffffffff864e58fe>] sctp_close+0x5fe/0x9b0 net/sctp/socket.c:1541
>  [<ffffffff85bfe691>] inet_release+0x111/0x270 net/ipv4/af_inet.c:413
>  [<ffffffff85d60ce5>] inet6_release+0x55/0x90 net/ipv6/af_inet6.c:406
>  [<ffffffff856b3b96>] sock_release+0x96/0x260 net/socket.c:571
>  [<ffffffff856b3d76>] sock_close+0x16/0x20 net/socket.c:1022
>  [<ffffffff8189d304>] __fput+0x244/0x860 fs/file_table.c:208
>  [<ffffffff8189d9b5>] ____fput+0x15/0x20 fs/file_table.c:244
>  [<ffffffff813e2dc0>] task_work_run+0x130/0x240 kernel/task_work.c:115
>  [<     inline     >] exit_task_work include/linux/task_work.h:21
>  [<ffffffff8137d1e5>] do_exit+0x885/0x3050 kernel/exit.c:750
>  [<ffffffff8137fb0c>] do_group_exit+0xec/0x390 kernel/exit.c:880
>  [<     inline     >] SYSC_exit_group kernel/exit.c:891
>  [<ffffffff8137fdcd>] SyS_exit_group+0x1d/0x20 kernel/exit.c:889
>  [<ffffffff86a924f6>] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> =================================
>
> On commit aa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85 (Nov 8).
> Eric, this now includes your patches that you previously pointed me
> to, and also https://patchwork.ozlabs.org/patch/553068/ on top of it.

Sure, I believe SCTP crowd already know they are missing ipv6_dup_options()

$ git grep -n ipv6_dup_options
include/net/ipv6.h:300:struct ipv6_txoptions *ipv6_dup_options(struct sock *sk,
net/dccp/ipv6.c:499:            opt = ipv6_dup_options(newsk, opt);
net/ipv6/exthdrs.c:714:ipv6_dup_options(struct sock *sk, struct
ipv6_txoptions *opt)
net/ipv6/exthdrs.c:734:EXPORT_SYMBOL_GPL(ipv6_dup_options);
net/ipv6/tcp_ipv6.c:1107:               opt = ipv6_dup_options(newsk, opt);

I can certainly send a patch, but maybe someone already cooked it and
is testing it ?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: use-after-free in inet6_destroy_sock
  2015-12-09 14:43   ` Eric Dumazet
@ 2015-12-09 14:59     ` Marcelo Ricardo Leitner
  -1 siblings, 0 replies; 34+ messages in thread
From: Marcelo Ricardo Leitner @ 2015-12-09 14:59 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Dmitry Vyukov, David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Wed, Dec 09, 2015 at 06:43:28AM -0800, Eric Dumazet wrote:
> On Wed, Dec 9, 2015 at 6:15 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> > Hello,
> >
> > The following program causes use-after-free in inet6_destroy_sock:
> >
> > // autogenerated by syzkaller (http://github.com/google/syzkaller)
> > #include <syscall.h>
> > #include <string.h>
> > #include <stdint.h>
> > #include <pthread.h>
> > #include <sys/types.h>
> > #include <sys/socket.h>
> > #include <linux/in.h>
> > #include <linux/in6.h>
> >
> > int cfd = -1;
> >
> > void *thr(void *arg)
> > {
> >         cfd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
> >         struct sockaddr_in6 sa = {};
> >         sa.sin6_family = AF_INET6;
> >         sa.sin6_port = getpid();
> >         sa.sin6_addr.s6_addr[15] = 1;
> >         syscall(SYS_connect, cfd, &sa, sizeof(sa), 0, 0, 0);
> >         return 0;
> > }
> >
> > int main()
> > {
> >         syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul,
> > 0xfffffffffffffffful, 0x0ul);
> >         int fd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
> >         struct sockaddr_in6 sa = {};
> >         sa.sin6_family = AF_INET6;
> >         sa.sin6_port = getpid();
> >         sa.sin6_addr.s6_addr[15] = 1;
> >         syscall(SYS_bind, fd, &sa, sizeof(sa), 0, 0, 0);
> >         syscall(SYS_listen, fd, 0x3ul, 0, 0, 0, 0);
> >         memcpy((void*)0x20002ff6,
> > "\x10\x48\xe0\xad\x68\xc0\xce\x4c\xd0\xb5", 10);
> >         syscall(SYS_setsockopt, fd, 0x29ul, 0x6ul, 0x20002ff6ul, 0xaul, 0);
> >         pthread_t th;
> >         pthread_create(&th, 0, thr, 0);
> >         pthread_join(th, 0);
> >         int sfd = syscall(SYS_accept4, fd, 0x20003f80ul, 0x20003ab4ul,
> > 0x80800ul, 0, 0);
> >         dup3(fd, -1, 0x80000);
> >         return 0;
> > }
> >
> >
> > ==================================================================
> > BUG: KASAN: use-after-free in inet6_destroy_sock+0x177/0x1c0 at addr
> > ffff8800349179b4
> > Read of size 4 by task executor/7001
> > =============================================================================
> > BUG kmalloc-96 (Not tainted): kasan: bad access detected
> > -----------------------------------------------------------------------------
> >
> > Disabling lock debugging due to kernel taint
> > INFO: Allocated in sock_kmalloc+0x93/0x100 age=20 cpu=0 pid=7064
> > [<      none      >] ___slab_alloc+0x648/0x8c0 mm/slub.c:2468
> > [<      none      >] __slab_alloc+0x4c/0x90 mm/slub.c:2497
> > [<     inline     >] slab_alloc_node mm/slub.c:2560
> > [<     inline     >] slab_alloc mm/slub.c:2602
> > [<      none      >] __kmalloc+0x2d9/0x480 mm/slub.c:3562
> > [<     inline     >] kmalloc include/linux/slab.h:463
> > [<      none      >] sock_kmalloc+0x93/0x100 net/core/sock.c:1771
> > [<      none      >] do_ipv6_setsockopt.isra.5+0x1f43/0x2e50
> > net/ipv6/ipv6_sockglue.c:490
> > [<      none      >] ipv6_setsockopt+0x4f/0x150 net/ipv6/ipv6_sockglue.c:895
> > [<      none      >] sctp_setsockopt+0x194/0x4020 net/sctp/socket.c:3702
> > [<      none      >] sock_common_setsockopt+0xb4/0x140 net/core/sock.c:2641
> > [<     inline     >] SYSC_setsockopt net/socket.c:1750
> > [<      none      >] SyS_setsockopt+0x161/0x290 net/socket.c:1729
> > [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a
> > arch/x86/entry/entry_64.S:185
> >
> > INFO: Freed in rcu_process_callbacks+0x52c/0x19e0 age=16 cpu=0 pid=0
> > [<      none      >] __slab_free+0x21e/0x3e0 mm/slub.c:2678
> > [<     inline     >] slab_free mm/slub.c:2833
> > [<      none      >] kfree+0x26f/0x3e0 mm/slub.c:3662
> > [<     inline     >] __rcu_reclaim kernel/rcu/rcu.h:113
> > [<     inline     >] rcu_do_batch kernel/rcu/tree.c:2693
> > [<     inline     >] invoke_rcu_callbacks kernel/rcu/tree.c:2961
> > [<     inline     >] __rcu_process_callbacks kernel/rcu/tree.c:2928
> > [<      none      >] rcu_process_callbacks+0x52c/0x19e0 kernel/rcu/tree.c:2945
> > [<      none      >] __do_softirq+0x2e5/0xb40 kernel/softirq.c:273
> > [<     inline     >] invoke_softirq kernel/softirq.c:350
> > [<      none      >] irq_exit+0x165/0x1e0 kernel/softirq.c:391
> > [<     inline     >] exiting_irq ./arch/x86/include/asm/apic.h:653
> > [<      none      >] smp_apic_timer_interrupt+0x88/0xc0
> > arch/x86/kernel/apic/apic.c:926
> > [<      none      >] apic_timer_interrupt+0x8c/0xa0
> > arch/x86/entry/entry_64.S:520
> > [<     inline     >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:111
> > [<      none      >] default_idle+0x22/0x300 arch/x86/kernel/process.c:304
> > [<      none      >] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:295
> > [<      none      >] default_idle_call+0x4f/0x80 kernel/sched/idle.c:92
> > [<     inline     >] cpuidle_idle_call kernel/sched/idle.c:156
> > [<     inline     >] cpu_idle_loop kernel/sched/idle.c:251
> > [<      none      >] cpu_startup_entry+0x481/0x690 kernel/sched/idle.c:299
> > [<      none      >] rest_init+0x1c7/0x1d0 init/main.c:412
> > [<      none      >] start_kernel+0x6cd/0x6f3 init/main.c:683
> > [<      none      >] x86_64_start_reservations+0x2a/0x2c
> > arch/x86/kernel/head64.c:195
> > [<      none      >] x86_64_start_kernel+0x176/0x185
> > arch/x86/kernel/head64.c:184
> >
> > INFO: Slab 0xffffea0000d24500 objects=28 used=26 fp=0xffff8800349179b0
> > flags=0x1fffc0000004080
> > INFO: Object 0xffff8800349179b0 @offset=14768 fp=0xffff880034914000
> > CPU: 1 PID: 7001 Comm: executor Tainted: G    B           4.4.0-rc4+ #158
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> >  0000000000000001 ffff880062eef940 ffffffff82e0f6d8 0000000041b58ab3
> >  ffffffff87aa2c7d ffffffff82e0f626 ffff88006c051740 ffffffff87ac3e19
> >  ffff88003e804900 0000000000000008 ffff8800349179b0 ffff880062eef940
> >
> > Call Trace:
> >  [<ffffffff818450f4>] __asan_report_load4_noabort+0x54/0x70
> > mm/kasan/report.c:294
> >  [<ffffffff85d61f17>] inet6_destroy_sock+0x177/0x1c0 net/ipv6/af_inet6.c:433
> >  [<ffffffff864df89d>] sctp_v6_destroy_sock+0x1d/0x20 net/sctp/socket.c:7389
> >  [<ffffffff856cf00d>] sk_common_release+0x7d/0x3e0 net/core/sock.c:2662
> >  [<ffffffff864e58fe>] sctp_close+0x5fe/0x9b0 net/sctp/socket.c:1541
> >  [<ffffffff85bfe691>] inet_release+0x111/0x270 net/ipv4/af_inet.c:413
> >  [<ffffffff85d60ce5>] inet6_release+0x55/0x90 net/ipv6/af_inet6.c:406
> >  [<ffffffff856b3b96>] sock_release+0x96/0x260 net/socket.c:571
> >  [<ffffffff856b3d76>] sock_close+0x16/0x20 net/socket.c:1022
> >  [<ffffffff8189d304>] __fput+0x244/0x860 fs/file_table.c:208
> >  [<ffffffff8189d9b5>] ____fput+0x15/0x20 fs/file_table.c:244
> >  [<ffffffff813e2dc0>] task_work_run+0x130/0x240 kernel/task_work.c:115
> >  [<     inline     >] exit_task_work include/linux/task_work.h:21
> >  [<ffffffff8137d1e5>] do_exit+0x885/0x3050 kernel/exit.c:750
> >  [<ffffffff8137fb0c>] do_group_exit+0xec/0x390 kernel/exit.c:880
> >  [<     inline     >] SYSC_exit_group kernel/exit.c:891
> >  [<ffffffff8137fdcd>] SyS_exit_group+0x1d/0x20 kernel/exit.c:889
> >  [<ffffffff86a924f6>] entry_SYSCALL_64_fastpath+0x16/0x7a
> > arch/x86/entry/entry_64.S:185
> > ==================================================================
> >
> > On commit aa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85 (Nov 8).
> > Eric, this now includes your patches that you previously pointed me
> > to, and also https://patchwork.ozlabs.org/patch/553068/ on top of it.
> 
> Sure, I believe SCTP crowd already know they are missing ipv6_dup_options()
> 
> $ git grep -n ipv6_dup_options
> include/net/ipv6.h:300:struct ipv6_txoptions *ipv6_dup_options(struct sock *sk,
> net/dccp/ipv6.c:499:            opt = ipv6_dup_options(newsk, opt);
> net/ipv6/exthdrs.c:714:ipv6_dup_options(struct sock *sk, struct
> ipv6_txoptions *opt)
> net/ipv6/exthdrs.c:734:EXPORT_SYMBOL_GPL(ipv6_dup_options);
> net/ipv6/tcp_ipv6.c:1107:               opt = ipv6_dup_options(newsk, opt);
> 
> I can certainly send a patch, but maybe someone already cooked it and
> is testing it ?

Speaking for me, I don't have it yet, at least not that fast. ;)

But I definitely can handle this, just please let me know. I'll be on
hold now.  Thanks

  Marcelo


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: use-after-free in inet6_destroy_sock
@ 2015-12-09 14:59     ` Marcelo Ricardo Leitner
  0 siblings, 0 replies; 34+ messages in thread
From: Marcelo Ricardo Leitner @ 2015-12-09 14:59 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Dmitry Vyukov, David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Wed, Dec 09, 2015 at 06:43:28AM -0800, Eric Dumazet wrote:
> On Wed, Dec 9, 2015 at 6:15 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> > Hello,
> >
> > The following program causes use-after-free in inet6_destroy_sock:
> >
> > // autogenerated by syzkaller (http://github.com/google/syzkaller)
> > #include <syscall.h>
> > #include <string.h>
> > #include <stdint.h>
> > #include <pthread.h>
> > #include <sys/types.h>
> > #include <sys/socket.h>
> > #include <linux/in.h>
> > #include <linux/in6.h>
> >
> > int cfd = -1;
> >
> > void *thr(void *arg)
> > {
> >         cfd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
> >         struct sockaddr_in6 sa = {};
> >         sa.sin6_family = AF_INET6;
> >         sa.sin6_port = getpid();
> >         sa.sin6_addr.s6_addr[15] = 1;
> >         syscall(SYS_connect, cfd, &sa, sizeof(sa), 0, 0, 0);
> >         return 0;
> > }
> >
> > int main()
> > {
> >         syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul,
> > 0xfffffffffffffffful, 0x0ul);
> >         int fd = syscall(SYS_socket, PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
> >         struct sockaddr_in6 sa = {};
> >         sa.sin6_family = AF_INET6;
> >         sa.sin6_port = getpid();
> >         sa.sin6_addr.s6_addr[15] = 1;
> >         syscall(SYS_bind, fd, &sa, sizeof(sa), 0, 0, 0);
> >         syscall(SYS_listen, fd, 0x3ul, 0, 0, 0, 0);
> >         memcpy((void*)0x20002ff6,
> > "\x10\x48\xe0\xad\x68\xc0\xce\x4c\xd0\xb5", 10);
> >         syscall(SYS_setsockopt, fd, 0x29ul, 0x6ul, 0x20002ff6ul, 0xaul, 0);
> >         pthread_t th;
> >         pthread_create(&th, 0, thr, 0);
> >         pthread_join(th, 0);
> >         int sfd = syscall(SYS_accept4, fd, 0x20003f80ul, 0x20003ab4ul,
> > 0x80800ul, 0, 0);
> >         dup3(fd, -1, 0x80000);
> >         return 0;
> > }
> >
> >
> > =================================
> > BUG: KASAN: use-after-free in inet6_destroy_sock+0x177/0x1c0 at addr
> > ffff8800349179b4
> > Read of size 4 by task executor/7001
> > ======================================> > BUG kmalloc-96 (Not tainted): kasan: bad access detected
> > -----------------------------------------------------------------------------
> >
> > Disabling lock debugging due to kernel taint
> > INFO: Allocated in sock_kmalloc+0x93/0x100 age  cpu=0 pidp64
> > [<      none      >] ___slab_alloc+0x648/0x8c0 mm/slub.c:2468
> > [<      none      >] __slab_alloc+0x4c/0x90 mm/slub.c:2497
> > [<     inline     >] slab_alloc_node mm/slub.c:2560
> > [<     inline     >] slab_alloc mm/slub.c:2602
> > [<      none      >] __kmalloc+0x2d9/0x480 mm/slub.c:3562
> > [<     inline     >] kmalloc include/linux/slab.h:463
> > [<      none      >] sock_kmalloc+0x93/0x100 net/core/sock.c:1771
> > [<      none      >] do_ipv6_setsockopt.isra.5+0x1f43/0x2e50
> > net/ipv6/ipv6_sockglue.c:490
> > [<      none      >] ipv6_setsockopt+0x4f/0x150 net/ipv6/ipv6_sockglue.c:895
> > [<      none      >] sctp_setsockopt+0x194/0x4020 net/sctp/socket.c:3702
> > [<      none      >] sock_common_setsockopt+0xb4/0x140 net/core/sock.c:2641
> > [<     inline     >] SYSC_setsockopt net/socket.c:1750
> > [<      none      >] SyS_setsockopt+0x161/0x290 net/socket.c:1729
> > [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a
> > arch/x86/entry/entry_64.S:185
> >
> > INFO: Freed in rcu_process_callbacks+0x52c/0x19e0 age\x16 cpu=0 pid=0
> > [<      none      >] __slab_free+0x21e/0x3e0 mm/slub.c:2678
> > [<     inline     >] slab_free mm/slub.c:2833
> > [<      none      >] kfree+0x26f/0x3e0 mm/slub.c:3662
> > [<     inline     >] __rcu_reclaim kernel/rcu/rcu.h:113
> > [<     inline     >] rcu_do_batch kernel/rcu/tree.c:2693
> > [<     inline     >] invoke_rcu_callbacks kernel/rcu/tree.c:2961
> > [<     inline     >] __rcu_process_callbacks kernel/rcu/tree.c:2928
> > [<      none      >] rcu_process_callbacks+0x52c/0x19e0 kernel/rcu/tree.c:2945
> > [<      none      >] __do_softirq+0x2e5/0xb40 kernel/softirq.c:273
> > [<     inline     >] invoke_softirq kernel/softirq.c:350
> > [<      none      >] irq_exit+0x165/0x1e0 kernel/softirq.c:391
> > [<     inline     >] exiting_irq ./arch/x86/include/asm/apic.h:653
> > [<      none      >] smp_apic_timer_interrupt+0x88/0xc0
> > arch/x86/kernel/apic/apic.c:926
> > [<      none      >] apic_timer_interrupt+0x8c/0xa0
> > arch/x86/entry/entry_64.S:520
> > [<     inline     >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:111
> > [<      none      >] default_idle+0x22/0x300 arch/x86/kernel/process.c:304
> > [<      none      >] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:295
> > [<      none      >] default_idle_call+0x4f/0x80 kernel/sched/idle.c:92
> > [<     inline     >] cpuidle_idle_call kernel/sched/idle.c:156
> > [<     inline     >] cpu_idle_loop kernel/sched/idle.c:251
> > [<      none      >] cpu_startup_entry+0x481/0x690 kernel/sched/idle.c:299
> > [<      none      >] rest_init+0x1c7/0x1d0 init/main.c:412
> > [<      none      >] start_kernel+0x6cd/0x6f3 init/main.c:683
> > [<      none      >] x86_64_start_reservations+0x2a/0x2c
> > arch/x86/kernel/head64.c:195
> > [<      none      >] x86_64_start_kernel+0x176/0x185
> > arch/x86/kernel/head64.c:184
> >
> > INFO: Slab 0xffffea0000d24500 objects( used& fp=0xffff8800349179b0
> > flags=0x1fffc0000004080
> > INFO: Object 0xffff8800349179b0 @offset\x14768 fp=0xffff880034914000
> > CPU: 1 PID: 7001 Comm: executor Tainted: G    B           4.4.0-rc4+ #158
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> >  0000000000000001 ffff880062eef940 ffffffff82e0f6d8 0000000041b58ab3
> >  ffffffff87aa2c7d ffffffff82e0f626 ffff88006c051740 ffffffff87ac3e19
> >  ffff88003e804900 0000000000000008 ffff8800349179b0 ffff880062eef940
> >
> > Call Trace:
> >  [<ffffffff818450f4>] __asan_report_load4_noabort+0x54/0x70
> > mm/kasan/report.c:294
> >  [<ffffffff85d61f17>] inet6_destroy_sock+0x177/0x1c0 net/ipv6/af_inet6.c:433
> >  [<ffffffff864df89d>] sctp_v6_destroy_sock+0x1d/0x20 net/sctp/socket.c:7389
> >  [<ffffffff856cf00d>] sk_common_release+0x7d/0x3e0 net/core/sock.c:2662
> >  [<ffffffff864e58fe>] sctp_close+0x5fe/0x9b0 net/sctp/socket.c:1541
> >  [<ffffffff85bfe691>] inet_release+0x111/0x270 net/ipv4/af_inet.c:413
> >  [<ffffffff85d60ce5>] inet6_release+0x55/0x90 net/ipv6/af_inet6.c:406
> >  [<ffffffff856b3b96>] sock_release+0x96/0x260 net/socket.c:571
> >  [<ffffffff856b3d76>] sock_close+0x16/0x20 net/socket.c:1022
> >  [<ffffffff8189d304>] __fput+0x244/0x860 fs/file_table.c:208
> >  [<ffffffff8189d9b5>] ____fput+0x15/0x20 fs/file_table.c:244
> >  [<ffffffff813e2dc0>] task_work_run+0x130/0x240 kernel/task_work.c:115
> >  [<     inline     >] exit_task_work include/linux/task_work.h:21
> >  [<ffffffff8137d1e5>] do_exit+0x885/0x3050 kernel/exit.c:750
> >  [<ffffffff8137fb0c>] do_group_exit+0xec/0x390 kernel/exit.c:880
> >  [<     inline     >] SYSC_exit_group kernel/exit.c:891
> >  [<ffffffff8137fdcd>] SyS_exit_group+0x1d/0x20 kernel/exit.c:889
> >  [<ffffffff86a924f6>] entry_SYSCALL_64_fastpath+0x16/0x7a
> > arch/x86/entry/entry_64.S:185
> > =================================
> >
> > On commit aa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85 (Nov 8).
> > Eric, this now includes your patches that you previously pointed me
> > to, and also https://patchwork.ozlabs.org/patch/553068/ on top of it.
> 
> Sure, I believe SCTP crowd already know they are missing ipv6_dup_options()
> 
> $ git grep -n ipv6_dup_options
> include/net/ipv6.h:300:struct ipv6_txoptions *ipv6_dup_options(struct sock *sk,
> net/dccp/ipv6.c:499:            opt = ipv6_dup_options(newsk, opt);
> net/ipv6/exthdrs.c:714:ipv6_dup_options(struct sock *sk, struct
> ipv6_txoptions *opt)
> net/ipv6/exthdrs.c:734:EXPORT_SYMBOL_GPL(ipv6_dup_options);
> net/ipv6/tcp_ipv6.c:1107:               opt = ipv6_dup_options(newsk, opt);
> 
> I can certainly send a patch, but maybe someone already cooked it and
> is testing it ?

Speaking for me, I don't have it yet, at least not that fast. ;)

But I definitely can handle this, just please let me know. I'll be on
hold now.  Thanks

  Marcelo


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: use-after-free in inet6_destroy_sock
  2015-12-09 14:59     ` Marcelo Ricardo Leitner
@ 2015-12-09 15:09       ` Eric Dumazet
  -1 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-09 15:09 UTC (permalink / raw)
  To: Marcelo Ricardo Leitner
  Cc: Dmitry Vyukov, David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Wed, Dec 9, 2015 at 6:59 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Dec 09, 2015 at 06:43:28AM -0800, Eric Dumazet wrote:
>
>> I can certainly send a patch, but maybe someone already cooked it and
>> is testing it ?
>
> Speaking for me, I don't have it yet, at least not that fast. ;)
>
> But I definitely can handle this, just please let me know. I'll be on
> hold now.  Thanks

I'll cook it right now, no worries.

Thanks.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: use-after-free in inet6_destroy_sock
@ 2015-12-09 15:09       ` Eric Dumazet
  0 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-09 15:09 UTC (permalink / raw)
  To: Marcelo Ricardo Leitner
  Cc: Dmitry Vyukov, David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Wed, Dec 9, 2015 at 6:59 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Dec 09, 2015 at 06:43:28AM -0800, Eric Dumazet wrote:
>
>> I can certainly send a patch, but maybe someone already cooked it and
>> is testing it ?
>
> Speaking for me, I don't have it yet, at least not that fast. ;)
>
> But I definitely can handle this, just please let me know. I'll be on
> hold now.  Thanks

I'll cook it right now, no worries.

Thanks.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-09 15:09       ` Eric Dumazet
@ 2015-12-09 15:25         ` Eric Dumazet
  -1 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-09 15:25 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Marcelo Ricardo Leitner, Dmitry Vyukov, David S. Miller,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	Patrick McHardy, netdev, LKML, Vlad Yasevich, Neil Horman,
	linux-sctp, syzkaller, Kostya Serebryany, Alexander Potapenko,
	Sasha Levin

From: Eric Dumazet <edumazet@google.com>

SCTP is lacking proper np->opt cloning at accept() time.

TCP and DCCP use ipv6_dup_options() helper, do the same
in SCTP.

We might later factorize this code in a common helper to avoid
future mistakes.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/sctp/ipv6.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index d28c0b4c9128..ec529121f38a 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -641,6 +641,7 @@ static struct sock *sctp_v6_create_accept_sk(struct sock *sk,
 	struct sock *newsk;
 	struct ipv6_pinfo *newnp, *np = inet6_sk(sk);
 	struct sctp6_sock *newsctp6sk;
+	struct ipv6_txoptions *opt;
 
 	newsk = sk_alloc(sock_net(sk), PF_INET6, GFP_KERNEL, sk->sk_prot, 0);
 	if (!newsk)
@@ -660,6 +661,13 @@ static struct sock *sctp_v6_create_accept_sk(struct sock *sk,
 
 	memcpy(newnp, np, sizeof(struct ipv6_pinfo));
 
+	rcu_read_lock();
+	opt = rcu_dereference(np->opt);
+	if (opt)
+		opt = ipv6_dup_options(newsk, opt);
+	RCU_INIT_POINTER(newnp->opt, opt);
+	rcu_read_unlock();
+
 	/* Initialize sk's sport, dport, rcv_saddr and daddr for getsockname()
 	 * and getpeername().
 	 */



^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-09 15:25         ` Eric Dumazet
  0 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-09 15:25 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Marcelo Ricardo Leitner, Dmitry Vyukov, David S. Miller,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	Patrick McHardy, netdev, LKML, Vlad Yasevich, Neil Horman,
	linux-sctp, syzkaller, Kostya Serebryany, Alexander Potapenko,
	Sasha Levin

From: Eric Dumazet <edumazet@google.com>

SCTP is lacking proper np->opt cloning at accept() time.

TCP and DCCP use ipv6_dup_options() helper, do the same
in SCTP.

We might later factorize this code in a common helper to avoid
future mistakes.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/sctp/ipv6.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index d28c0b4c9128..ec529121f38a 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -641,6 +641,7 @@ static struct sock *sctp_v6_create_accept_sk(struct sock *sk,
 	struct sock *newsk;
 	struct ipv6_pinfo *newnp, *np = inet6_sk(sk);
 	struct sctp6_sock *newsctp6sk;
+	struct ipv6_txoptions *opt;
 
 	newsk = sk_alloc(sock_net(sk), PF_INET6, GFP_KERNEL, sk->sk_prot, 0);
 	if (!newsk)
@@ -660,6 +661,13 @@ static struct sock *sctp_v6_create_accept_sk(struct sock *sk,
 
 	memcpy(newnp, np, sizeof(struct ipv6_pinfo));
 
+	rcu_read_lock();
+	opt = rcu_dereference(np->opt);
+	if (opt)
+		opt = ipv6_dup_options(newsk, opt);
+	RCU_INIT_POINTER(newnp->opt, opt);
+	rcu_read_unlock();
+
 	/* Initialize sk's sport, dport, rcv_saddr and daddr for getsockname()
 	 * and getpeername().
 	 */



^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-09 15:25         ` Eric Dumazet
@ 2015-12-09 15:34           ` Vlad Yasevich
  -1 siblings, 0 replies; 34+ messages in thread
From: Vlad Yasevich @ 2015-12-09 15:34 UTC (permalink / raw)
  To: Eric Dumazet, Eric Dumazet
  Cc: Marcelo Ricardo Leitner, Dmitry Vyukov, David S. Miller,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	Patrick McHardy, netdev, LKML, Neil Horman, linux-sctp,
	syzkaller, Kostya Serebryany, Alexander Potapenko, Sasha Levin

On 12/09/2015 10:25 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
> 
> SCTP is lacking proper np->opt cloning at accept() time.
> 
> TCP and DCCP use ipv6_dup_options() helper, do the same
> in SCTP.
> 
> We might later factorize this code in a common helper to avoid
> future mistakes.
> 
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Acked-by: Vlad Yasevich <vyasevich@gmail.com>

This is sufficient for accept() processing, but looks like peeloff is missing
a bunch of ipv6 support.  I'll see if I can cook something up to fix that part.

-vlad

> ---
>  net/sctp/ipv6.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
> index d28c0b4c9128..ec529121f38a 100644
> --- a/net/sctp/ipv6.c
> +++ b/net/sctp/ipv6.c
> @@ -641,6 +641,7 @@ static struct sock *sctp_v6_create_accept_sk(struct sock *sk,
>  	struct sock *newsk;
>  	struct ipv6_pinfo *newnp, *np = inet6_sk(sk);
>  	struct sctp6_sock *newsctp6sk;
> +	struct ipv6_txoptions *opt;
>  
>  	newsk = sk_alloc(sock_net(sk), PF_INET6, GFP_KERNEL, sk->sk_prot, 0);
>  	if (!newsk)
> @@ -660,6 +661,13 @@ static struct sock *sctp_v6_create_accept_sk(struct sock *sk,
>  
>  	memcpy(newnp, np, sizeof(struct ipv6_pinfo));
>  
> +	rcu_read_lock();
> +	opt = rcu_dereference(np->opt);
> +	if (opt)
> +		opt = ipv6_dup_options(newsk, opt);
> +	RCU_INIT_POINTER(newnp->opt, opt);
> +	rcu_read_unlock();
> +
>  	/* Initialize sk's sport, dport, rcv_saddr and daddr for getsockname()
>  	 * and getpeername().
>  	 */
> 
> 


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-09 15:34           ` Vlad Yasevich
  0 siblings, 0 replies; 34+ messages in thread
From: Vlad Yasevich @ 2015-12-09 15:34 UTC (permalink / raw)
  To: Eric Dumazet, Eric Dumazet
  Cc: Marcelo Ricardo Leitner, Dmitry Vyukov, David S. Miller,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	Patrick McHardy, netdev, LKML, Neil Horman, linux-sctp,
	syzkaller, Kostya Serebryany, Alexander Potapenko, Sasha Levin

On 12/09/2015 10:25 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
> 
> SCTP is lacking proper np->opt cloning at accept() time.
> 
> TCP and DCCP use ipv6_dup_options() helper, do the same
> in SCTP.
> 
> We might later factorize this code in a common helper to avoid
> future mistakes.
> 
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Acked-by: Vlad Yasevich <vyasevich@gmail.com>

This is sufficient for accept() processing, but looks like peeloff is missing
a bunch of ipv6 support.  I'll see if I can cook something up to fix that part.

-vlad

> ---
>  net/sctp/ipv6.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
> index d28c0b4c9128..ec529121f38a 100644
> --- a/net/sctp/ipv6.c
> +++ b/net/sctp/ipv6.c
> @@ -641,6 +641,7 @@ static struct sock *sctp_v6_create_accept_sk(struct sock *sk,
>  	struct sock *newsk;
>  	struct ipv6_pinfo *newnp, *np = inet6_sk(sk);
>  	struct sctp6_sock *newsctp6sk;
> +	struct ipv6_txoptions *opt;
>  
>  	newsk = sk_alloc(sock_net(sk), PF_INET6, GFP_KERNEL, sk->sk_prot, 0);
>  	if (!newsk)
> @@ -660,6 +661,13 @@ static struct sock *sctp_v6_create_accept_sk(struct sock *sk,
>  
>  	memcpy(newnp, np, sizeof(struct ipv6_pinfo));
>  
> +	rcu_read_lock();
> +	opt = rcu_dereference(np->opt);
> +	if (opt)
> +		opt = ipv6_dup_options(newsk, opt);
> +	RCU_INIT_POINTER(newnp->opt, opt);
> +	rcu_read_unlock();
> +
>  	/* Initialize sk's sport, dport, rcv_saddr and daddr for getsockname()
>  	 * and getpeername().
>  	 */
> 
> 


^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-09 15:25         ` Eric Dumazet
  (?)
@ 2015-12-09 15:49           ` David Laight
  -1 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-09 15:49 UTC (permalink / raw)
  To: 'Eric Dumazet', Eric Dumazet
  Cc: Marcelo Ricardo Leitner, Dmitry Vyukov, David S. Miller,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	Patrick McHardy, netdev, LKML, Vlad Yasevich, Neil Horman,
	linux-sctp, syzkaller, Kostya Serebryany, Alexander Potapenko,
	Sasha Levin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 665 bytes --]

> SCTP is lacking proper np->opt cloning at accept() time.
> 
> TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
> 
> We might later factorize this code in a common helper to avoid
> future mistakes.

I'm wondering what the real impact of this and the other recent
SCTP bugs/patches is on real workloads?
We have enough trouble getting our customers to use kernels
later that the 2.6.18 based RHEL5 - without having to persuade
them to use kernels that contain very recent fixes.

	David

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-09 15:49           ` David Laight
  0 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-09 15:49 UTC (permalink / raw)
  To: 'Eric Dumazet', Eric Dumazet
  Cc: Marcelo Ricardo Leitner, Dmitry Vyukov, David S. Miller,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	Patrick McHardy, netdev, LKML, Vlad Yasevich, Neil Horman,
	linux-sctp, syzkaller, Kostya Serebryany, Alexander Potapenko,
	Sasha Levin

> SCTP is lacking proper np->opt cloning at accept() time.
> 
> TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
> 
> We might later factorize this code in a common helper to avoid
> future mistakes.

I'm wondering what the real impact of this and the other recent
SCTP bugs/patches is on real workloads?
We have enough trouble getting our customers to use kernels
later that the 2.6.18 based RHEL5 - without having to persuade
them to use kernels that contain very recent fixes.

	David


^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-09 15:49           ` David Laight
  0 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-09 15:49 UTC (permalink / raw)
  To: 'Eric Dumazet', Eric Dumazet
  Cc: Marcelo Ricardo Leitner, Dmitry Vyukov, David S. Miller,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	Patrick McHardy, netdev, LKML, Vlad Yasevich, Neil Horman,
	linux-sctp, syzkaller, Kostya Serebryany, Alexander Potapenko,
	Sasha Levin

PiBTQ1RQIGlzIGxhY2tpbmcgcHJvcGVyIG5wLT5vcHQgY2xvbmluZyBhdCBhY2NlcHQoKSB0aW1l
Lg0KPiANCj4gVENQIGFuZCBEQ0NQIHVzZSBpcHY2X2R1cF9vcHRpb25zKCkgaGVscGVyLCBkbyB0
aGUgc2FtZSBpbiBTQ1RQLg0KPiANCj4gV2UgbWlnaHQgbGF0ZXIgZmFjdG9yaXplIHRoaXMgY29k
ZSBpbiBhIGNvbW1vbiBoZWxwZXIgdG8gYXZvaWQNCj4gZnV0dXJlIG1pc3Rha2VzLg0KDQpJJ20g
d29uZGVyaW5nIHdoYXQgdGhlIHJlYWwgaW1wYWN0IG9mIHRoaXMgYW5kIHRoZSBvdGhlciByZWNl
bnQNClNDVFAgYnVncy9wYXRjaGVzIGlzIG9uIHJlYWwgd29ya2xvYWRzPw0KV2UgaGF2ZSBlbm91
Z2ggdHJvdWJsZSBnZXR0aW5nIG91ciBjdXN0b21lcnMgdG8gdXNlIGtlcm5lbHMNCmxhdGVyIHRo
YXQgdGhlIDIuNi4xOCBiYXNlZCBSSEVMNSAtIHdpdGhvdXQgaGF2aW5nIHRvIHBlcnN1YWRlDQp0
aGVtIHRvIHVzZSBrZXJuZWxzIHRoYXQgY29udGFpbiB2ZXJ5IHJlY2VudCBmaXhlcy4NCg0KCURh
dmlkDQoNCg=

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-09 15:49           ` David Laight
@ 2015-12-09 15:59             ` Eric Dumazet
  -1 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-09 15:59 UTC (permalink / raw)
  To: David Laight
  Cc: Eric Dumazet, Marcelo Ricardo Leitner, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
> > SCTP is lacking proper np->opt cloning at accept() time.
> > 
> > TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
> > 
> > We might later factorize this code in a common helper to avoid
> > future mistakes.
> 
> I'm wondering what the real impact of this and the other recent
> SCTP bugs/patches is on real workloads?
> We have enough trouble getting our customers to use kernels
> later that the 2.6.18 based RHEL5 - without having to persuade
> them to use kernels that contain very recent fixes.

It all depends if your customers let (hostile ?) people run programs on
the boxes.

I wont run the program on my laptop just for the fun of making it crash,
but I guess Cloud providers might be worried, once exploits are public.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-09 15:59             ` Eric Dumazet
  0 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-09 15:59 UTC (permalink / raw)
  To: David Laight
  Cc: Eric Dumazet, Marcelo Ricardo Leitner, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
> > SCTP is lacking proper np->opt cloning at accept() time.
> > 
> > TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
> > 
> > We might later factorize this code in a common helper to avoid
> > future mistakes.
> 
> I'm wondering what the real impact of this and the other recent
> SCTP bugs/patches is on real workloads?
> We have enough trouble getting our customers to use kernels
> later that the 2.6.18 based RHEL5 - without having to persuade
> them to use kernels that contain very recent fixes.

It all depends if your customers let (hostile ?) people run programs on
the boxes.

I wont run the program on my laptop just for the fun of making it crash,
but I guess Cloud providers might be worried, once exploits are public.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-09 15:59             ` Eric Dumazet
  (?)
@ 2015-12-09 16:31               ` David Laight
  -1 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-09 16:31 UTC (permalink / raw)
  To: 'Eric Dumazet'
  Cc: Eric Dumazet, Marcelo Ricardo Leitner, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1163 bytes --]

From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: 09 December 2015 16:00
> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
> > > SCTP is lacking proper np->opt cloning at accept() time.
> > >
> > > TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
> > >
> > > We might later factorize this code in a common helper to avoid
> > > future mistakes.
> >
> > I'm wondering what the real impact of this and the other recent
> > SCTP bugs/patches is on real workloads?
> > We have enough trouble getting our customers to use kernels
> > later that the 2.6.18 based RHEL5 - without having to persuade
> > them to use kernels that contain very recent fixes.
> 
> It all depends if your customers let (hostile ?) people run programs on
> the boxes.

If they require hostile programs I'm not worried.

But it isn't entirely clear from these oops reports what the
test program is actually doing.
Some of them might be valid scenarios.
Not that our code does anything clever.

	David

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-09 16:31               ` David Laight
  0 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-09 16:31 UTC (permalink / raw)
  To: 'Eric Dumazet'
  Cc: Eric Dumazet, Marcelo Ricardo Leitner, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: 09 December 2015 16:00
> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
> > > SCTP is lacking proper np->opt cloning at accept() time.
> > >
> > > TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
> > >
> > > We might later factorize this code in a common helper to avoid
> > > future mistakes.
> >
> > I'm wondering what the real impact of this and the other recent
> > SCTP bugs/patches is on real workloads?
> > We have enough trouble getting our customers to use kernels
> > later that the 2.6.18 based RHEL5 - without having to persuade
> > them to use kernels that contain very recent fixes.
> 
> It all depends if your customers let (hostile ?) people run programs on
> the boxes.

If they require hostile programs I'm not worried.

But it isn't entirely clear from these oops reports what the
test program is actually doing.
Some of them might be valid scenarios.
Not that our code does anything clever.

	David


^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-09 16:31               ` David Laight
  0 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-09 16:31 UTC (permalink / raw)
  To: 'Eric Dumazet'
  Cc: Eric Dumazet, Marcelo Ricardo Leitner, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

RnJvbTogRXJpYyBEdW1hemV0IFttYWlsdG86ZXJpYy5kdW1hemV0QGdtYWlsLmNvbV0NCj4gU2Vu
dDogMDkgRGVjZW1iZXIgMjAxNSAxNjowMA0KPiBPbiBXZWQsIDIwMTUtMTItMDkgYXQgMTU6NDkg
KzAwMDAsIERhdmlkIExhaWdodCB3cm90ZToNCj4gPiA+IFNDVFAgaXMgbGFja2luZyBwcm9wZXIg
bnAtPm9wdCBjbG9uaW5nIGF0IGFjY2VwdCgpIHRpbWUuDQo+ID4gPg0KPiA+ID4gVENQIGFuZCBE
Q0NQIHVzZSBpcHY2X2R1cF9vcHRpb25zKCkgaGVscGVyLCBkbyB0aGUgc2FtZSBpbiBTQ1RQLg0K
PiA+ID4NCj4gPiA+IFdlIG1pZ2h0IGxhdGVyIGZhY3Rvcml6ZSB0aGlzIGNvZGUgaW4gYSBjb21t
b24gaGVscGVyIHRvIGF2b2lkDQo+ID4gPiBmdXR1cmUgbWlzdGFrZXMuDQo+ID4NCj4gPiBJJ20g
d29uZGVyaW5nIHdoYXQgdGhlIHJlYWwgaW1wYWN0IG9mIHRoaXMgYW5kIHRoZSBvdGhlciByZWNl
bnQNCj4gPiBTQ1RQIGJ1Z3MvcGF0Y2hlcyBpcyBvbiByZWFsIHdvcmtsb2Fkcz8NCj4gPiBXZSBo
YXZlIGVub3VnaCB0cm91YmxlIGdldHRpbmcgb3VyIGN1c3RvbWVycyB0byB1c2Uga2VybmVscw0K
PiA+IGxhdGVyIHRoYXQgdGhlIDIuNi4xOCBiYXNlZCBSSEVMNSAtIHdpdGhvdXQgaGF2aW5nIHRv
IHBlcnN1YWRlDQo+ID4gdGhlbSB0byB1c2Uga2VybmVscyB0aGF0IGNvbnRhaW4gdmVyeSByZWNl
bnQgZml4ZXMuDQo+IA0KPiBJdCBhbGwgZGVwZW5kcyBpZiB5b3VyIGN1c3RvbWVycyBsZXQgKGhv
c3RpbGUgPykgcGVvcGxlIHJ1biBwcm9ncmFtcyBvbg0KPiB0aGUgYm94ZXMuDQoNCklmIHRoZXkg
cmVxdWlyZSBob3N0aWxlIHByb2dyYW1zIEknbSBub3Qgd29ycmllZC4NCg0KQnV0IGl0IGlzbid0
IGVudGlyZWx5IGNsZWFyIGZyb20gdGhlc2Ugb29wcyByZXBvcnRzIHdoYXQgdGhlDQp0ZXN0IHBy
b2dyYW0gaXMgYWN0dWFsbHkgZG9pbmcuDQpTb21lIG9mIHRoZW0gbWlnaHQgYmUgdmFsaWQgc2Nl
bmFyaW9zLg0KTm90IHRoYXQgb3VyIGNvZGUgZG9lcyBhbnl0aGluZyBjbGV2ZXIuDQoNCglEYXZp
ZA0KDQo

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-09 16:31               ` David Laight
@ 2015-12-09 17:11                 ` Marcelo Ricardo Leitner
  -1 siblings, 0 replies; 34+ messages in thread
From: Marcelo Ricardo Leitner @ 2015-12-09 17:11 UTC (permalink / raw)
  To: David Laight, 'Eric Dumazet'
  Cc: Eric Dumazet, Dmitry Vyukov, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
	Vlad Yasevich, Neil Horman, linux-sctp, syzkaller,
	Kostya Serebryany, Alexander Potapenko, Sasha Levin

Em 09-12-2015 14:31, David Laight escreveu:
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>> Sent: 09 December 2015 16:00
>> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
>>>> SCTP is lacking proper np->opt cloning at accept() time.
>>>>
>>>> TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
>>>>
>>>> We might later factorize this code in a common helper to avoid
>>>> future mistakes.
>>>
>>> I'm wondering what the real impact of this and the other recent
>>> SCTP bugs/patches is on real workloads?
>>> We have enough trouble getting our customers to use kernels
>>> later that the 2.6.18 based RHEL5 - without having to persuade
>>> them to use kernels that contain very recent fixes.
>>
>> It all depends if your customers let (hostile ?) people run programs on
>> the boxes.
>
> If they require hostile programs I'm not worried.

Not really "require", but "allow", as in: allowing third-party 
applications to run on it.

> But it isn't entirely clear from these oops reports what the
> test program is actually doing.
> Some of them might be valid scenarios.
> Not that our code does anything clever.

This one patched by Eric is a rather common scenario and can lead to 
memory corruption and even double-frees because it will call txopt_put() 
on a buffer that is long gone due to the blind pointer copy. Note that 
Vlad is checking peeloff operation yet regarding this.
You just have to use the right SOL_IPV6 options and accept a socket to 
trigger it.

The timestamps I patched are also not an unusual scenario and allow one 
to be able to disable packet stamping for the entire system. Another 
effect would be to one enable stamping on listening socket and not gett 
it automatically on accepted ones, but that's probably a minor compared 
to the others because developers probably would have caught this already.

And this last one I'm still fixing, is mostly harmless so far. The 
use-after-free happens only in a debug statement (read: not propagated 
anywhere else) and it's just a read.

HTH!

   Marcelo


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-09 17:11                 ` Marcelo Ricardo Leitner
  0 siblings, 0 replies; 34+ messages in thread
From: Marcelo Ricardo Leitner @ 2015-12-09 17:11 UTC (permalink / raw)
  To: David Laight, 'Eric Dumazet'
  Cc: Eric Dumazet, Dmitry Vyukov, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
	Vlad Yasevich, Neil Horman, linux-sctp, syzkaller,
	Kostya Serebryany, Alexander Potapenko, Sasha Levin

Em 09-12-2015 14:31, David Laight escreveu:
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>> Sent: 09 December 2015 16:00
>> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
>>>> SCTP is lacking proper np->opt cloning at accept() time.
>>>>
>>>> TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
>>>>
>>>> We might later factorize this code in a common helper to avoid
>>>> future mistakes.
>>>
>>> I'm wondering what the real impact of this and the other recent
>>> SCTP bugs/patches is on real workloads?
>>> We have enough trouble getting our customers to use kernels
>>> later that the 2.6.18 based RHEL5 - without having to persuade
>>> them to use kernels that contain very recent fixes.
>>
>> It all depends if your customers let (hostile ?) people run programs on
>> the boxes.
>
> If they require hostile programs I'm not worried.

Not really "require", but "allow", as in: allowing third-party 
applications to run on it.

> But it isn't entirely clear from these oops reports what the
> test program is actually doing.
> Some of them might be valid scenarios.
> Not that our code does anything clever.

This one patched by Eric is a rather common scenario and can lead to 
memory corruption and even double-frees because it will call txopt_put() 
on a buffer that is long gone due to the blind pointer copy. Note that 
Vlad is checking peeloff operation yet regarding this.
You just have to use the right SOL_IPV6 options and accept a socket to 
trigger it.

The timestamps I patched are also not an unusual scenario and allow one 
to be able to disable packet stamping for the entire system. Another 
effect would be to one enable stamping on listening socket and not gett 
it automatically on accepted ones, but that's probably a minor compared 
to the others because developers probably would have caught this already.

And this last one I'm still fixing, is mostly harmless so far. The 
use-after-free happens only in a debug statement (read: not propagated 
anywhere else) and it's just a read.

HTH!

   Marcelo


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-09 17:11                 ` Marcelo Ricardo Leitner
@ 2015-12-09 19:19                   ` Daniel Borkmann
  -1 siblings, 0 replies; 34+ messages in thread
From: Daniel Borkmann @ 2015-12-09 19:19 UTC (permalink / raw)
  To: Marcelo Ricardo Leitner, David Laight, 'Eric Dumazet'
  Cc: Eric Dumazet, Dmitry Vyukov, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
	Vlad Yasevich, Neil Horman, linux-sctp, syzkaller,
	Kostya Serebryany, Alexander Potapenko, Sasha Levin

On 12/09/2015 06:11 PM, Marcelo Ricardo Leitner wrote:
> Em 09-12-2015 14:31, David Laight escreveu:
>> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>>> Sent: 09 December 2015 16:00
>>> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
>>>>> SCTP is lacking proper np->opt cloning at accept() time.
>>>>>
>>>>> TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
>>>>>
>>>>> We might later factorize this code in a common helper to avoid
>>>>> future mistakes.
>>>>
>>>> I'm wondering what the real impact of this and the other recent
>>>> SCTP bugs/patches is on real workloads?
>>>> We have enough trouble getting our customers to use kernels
>>>> later that the 2.6.18 based RHEL5 - without having to persuade
>>>> them to use kernels that contain very recent fixes.
>>>
>>> It all depends if your customers let (hostile ?) people run programs on
>>> the boxes.
>>
>> If they require hostile programs I'm not worried.
>
> Not really "require", but "allow", as in: allowing third-party applications to run on it.

Yeah :/ given distros enable almost everything anyway, the first unpriv'ed
socket(..., IPPROTO_SCTP) call auto-loads SCTP module. But to be honest, I'd
be surprised if Cloud providers allow for this. Most of this might only run
on dedicated boxes with telco appliances.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-09 19:19                   ` Daniel Borkmann
  0 siblings, 0 replies; 34+ messages in thread
From: Daniel Borkmann @ 2015-12-09 19:19 UTC (permalink / raw)
  To: Marcelo Ricardo Leitner, David Laight, 'Eric Dumazet'
  Cc: Eric Dumazet, Dmitry Vyukov, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
	Vlad Yasevich, Neil Horman, linux-sctp, syzkaller,
	Kostya Serebryany, Alexander Potapenko, Sasha Levin

On 12/09/2015 06:11 PM, Marcelo Ricardo Leitner wrote:
> Em 09-12-2015 14:31, David Laight escreveu:
>> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>>> Sent: 09 December 2015 16:00
>>> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
>>>>> SCTP is lacking proper np->opt cloning at accept() time.
>>>>>
>>>>> TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
>>>>>
>>>>> We might later factorize this code in a common helper to avoid
>>>>> future mistakes.
>>>>
>>>> I'm wondering what the real impact of this and the other recent
>>>> SCTP bugs/patches is on real workloads?
>>>> We have enough trouble getting our customers to use kernels
>>>> later that the 2.6.18 based RHEL5 - without having to persuade
>>>> them to use kernels that contain very recent fixes.
>>>
>>> It all depends if your customers let (hostile ?) people run programs on
>>> the boxes.
>>
>> If they require hostile programs I'm not worried.
>
> Not really "require", but "allow", as in: allowing third-party applications to run on it.

Yeah :/ given distros enable almost everything anyway, the first unpriv'ed
socket(..., IPPROTO_SCTP) call auto-loads SCTP module. But to be honest, I'd
be surprised if Cloud providers allow for this. Most of this might only run
on dedicated boxes with telco appliances.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-09 19:19                   ` Daniel Borkmann
  (?)
@ 2015-12-10 12:26                     ` David Laight
  -1 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-10 12:26 UTC (permalink / raw)
  To: 'Daniel Borkmann',
	Marcelo Ricardo Leitner, 'Eric Dumazet'
  Cc: Eric Dumazet, Dmitry Vyukov, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
	Vlad Yasevich, Neil Horman, linux-sctp, syzkaller,
	Kostya Serebryany, Alexander Potapenko, Sasha Levin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1851 bytes --]

From: Daniel Borkmann
> Sent: 09 December 2015 19:19
> On 12/09/2015 06:11 PM, Marcelo Ricardo Leitner wrote:
> > Em 09-12-2015 14:31, David Laight escreveu:
> >> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> >>> Sent: 09 December 2015 16:00
> >>> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
> >>>>> SCTP is lacking proper np->opt cloning at accept() time.
> >>>>>
> >>>>> TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
> >>>>>
> >>>>> We might later factorize this code in a common helper to avoid
> >>>>> future mistakes.
> >>>>
> >>>> I'm wondering what the real impact of this and the other recent
> >>>> SCTP bugs/patches is on real workloads?
> >>>> We have enough trouble getting our customers to use kernels
> >>>> later that the 2.6.18 based RHEL5 - without having to persuade
> >>>> them to use kernels that contain very recent fixes.
> >>>
> >>> It all depends if your customers let (hostile ?) people run programs on
> >>> the boxes.
> >>
> >> If they require hostile programs I'm not worried.
> >
> > Not really "require", but "allow", as in: allowing third-party applications to run on it.
> 
> Yeah :/ given distros enable almost everything anyway, the first unpriv'ed
> socket(..., IPPROTO_SCTP) call auto-loads SCTP module. But to be honest, I'd
> be surprised if Cloud providers allow for this. Most of this might only run
> on dedicated boxes with telco appliances.

Yes, I'm worried about whether our M3UA code is likely to crash customer
systems, not whether hostile applications can crash it.
These boxes ought to be on private networks since the sigtran protocols
themselves have nothing that even gives a hint of security.

	David
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-10 12:26                     ` David Laight
  0 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-10 12:26 UTC (permalink / raw)
  To: 'Daniel Borkmann',
	Marcelo Ricardo Leitner, 'Eric Dumazet'
  Cc: Eric Dumazet, Dmitry Vyukov, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
	Vlad Yasevich, Neil Horman, linux-sctp, syzkaller,
	Kostya Serebryany, Alexander Potapenko, Sasha Levin

From: Daniel Borkmann
> Sent: 09 December 2015 19:19
> On 12/09/2015 06:11 PM, Marcelo Ricardo Leitner wrote:
> > Em 09-12-2015 14:31, David Laight escreveu:
> >> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> >>> Sent: 09 December 2015 16:00
> >>> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote:
> >>>>> SCTP is lacking proper np->opt cloning at accept() time.
> >>>>>
> >>>>> TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP.
> >>>>>
> >>>>> We might later factorize this code in a common helper to avoid
> >>>>> future mistakes.
> >>>>
> >>>> I'm wondering what the real impact of this and the other recent
> >>>> SCTP bugs/patches is on real workloads?
> >>>> We have enough trouble getting our customers to use kernels
> >>>> later that the 2.6.18 based RHEL5 - without having to persuade
> >>>> them to use kernels that contain very recent fixes.
> >>>
> >>> It all depends if your customers let (hostile ?) people run programs on
> >>> the boxes.
> >>
> >> If they require hostile programs I'm not worried.
> >
> > Not really "require", but "allow", as in: allowing third-party applications to run on it.
> 
> Yeah :/ given distros enable almost everything anyway, the first unpriv'ed
> socket(..., IPPROTO_SCTP) call auto-loads SCTP module. But to be honest, I'd
> be surprised if Cloud providers allow for this. Most of this might only run
> on dedicated boxes with telco appliances.

Yes, I'm worried about whether our M3UA code is likely to crash customer
systems, not whether hostile applications can crash it.
These boxes ought to be on private networks since the sigtran protocols
themselves have nothing that even gives a hint of security.

	David

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-10 12:26                     ` David Laight
  0 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-10 12:26 UTC (permalink / raw)
  To: 'Daniel Borkmann',
	Marcelo Ricardo Leitner, 'Eric Dumazet'
  Cc: Eric Dumazet, Dmitry Vyukov, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
	Vlad Yasevich, Neil Horman, linux-sctp, syzkaller,
	Kostya Serebryany, Alexander Potapenko, Sasha Levin

RnJvbTogRGFuaWVsIEJvcmttYW5uDQo+IFNlbnQ6IDA5IERlY2VtYmVyIDIwMTUgMTk6MTkNCj4g
T24gMTIvMDkvMjAxNSAwNjoxMSBQTSwgTWFyY2VsbyBSaWNhcmRvIExlaXRuZXIgd3JvdGU6DQo+
ID4gRW0gMDktMTItMjAxNSAxNDozMSwgRGF2aWQgTGFpZ2h0IGVzY3JldmV1Og0KPiA+PiBGcm9t
OiBFcmljIER1bWF6ZXQgW21haWx0bzplcmljLmR1bWF6ZXRAZ21haWwuY29tXQ0KPiA+Pj4gU2Vu
dDogMDkgRGVjZW1iZXIgMjAxNSAxNjowMA0KPiA+Pj4gT24gV2VkLCAyMDE1LTEyLTA5IGF0IDE1
OjQ5ICswMDAwLCBEYXZpZCBMYWlnaHQgd3JvdGU6DQo+ID4+Pj4+IFNDVFAgaXMgbGFja2luZyBw
cm9wZXIgbnAtPm9wdCBjbG9uaW5nIGF0IGFjY2VwdCgpIHRpbWUuDQo+ID4+Pj4+DQo+ID4+Pj4+
IFRDUCBhbmQgRENDUCB1c2UgaXB2Nl9kdXBfb3B0aW9ucygpIGhlbHBlciwgZG8gdGhlIHNhbWUg
aW4gU0NUUC4NCj4gPj4+Pj4NCj4gPj4+Pj4gV2UgbWlnaHQgbGF0ZXIgZmFjdG9yaXplIHRoaXMg
Y29kZSBpbiBhIGNvbW1vbiBoZWxwZXIgdG8gYXZvaWQNCj4gPj4+Pj4gZnV0dXJlIG1pc3Rha2Vz
Lg0KPiA+Pj4+DQo+ID4+Pj4gSSdtIHdvbmRlcmluZyB3aGF0IHRoZSByZWFsIGltcGFjdCBvZiB0
aGlzIGFuZCB0aGUgb3RoZXIgcmVjZW50DQo+ID4+Pj4gU0NUUCBidWdzL3BhdGNoZXMgaXMgb24g
cmVhbCB3b3JrbG9hZHM/DQo+ID4+Pj4gV2UgaGF2ZSBlbm91Z2ggdHJvdWJsZSBnZXR0aW5nIG91
ciBjdXN0b21lcnMgdG8gdXNlIGtlcm5lbHMNCj4gPj4+PiBsYXRlciB0aGF0IHRoZSAyLjYuMTgg
YmFzZWQgUkhFTDUgLSB3aXRob3V0IGhhdmluZyB0byBwZXJzdWFkZQ0KPiA+Pj4+IHRoZW0gdG8g
dXNlIGtlcm5lbHMgdGhhdCBjb250YWluIHZlcnkgcmVjZW50IGZpeGVzLg0KPiA+Pj4NCj4gPj4+
IEl0IGFsbCBkZXBlbmRzIGlmIHlvdXIgY3VzdG9tZXJzIGxldCAoaG9zdGlsZSA/KSBwZW9wbGUg
cnVuIHByb2dyYW1zIG9uDQo+ID4+PiB0aGUgYm94ZXMuDQo+ID4+DQo+ID4+IElmIHRoZXkgcmVx
dWlyZSBob3N0aWxlIHByb2dyYW1zIEknbSBub3Qgd29ycmllZC4NCj4gPg0KPiA+IE5vdCByZWFs
bHkgInJlcXVpcmUiLCBidXQgImFsbG93IiwgYXMgaW46IGFsbG93aW5nIHRoaXJkLXBhcnR5IGFw
cGxpY2F0aW9ucyB0byBydW4gb24gaXQuDQo+IA0KPiBZZWFoIDovIGdpdmVuIGRpc3Ryb3MgZW5h
YmxlIGFsbW9zdCBldmVyeXRoaW5nIGFueXdheSwgdGhlIGZpcnN0IHVucHJpdidlZA0KPiBzb2Nr
ZXQoLi4uLCBJUFBST1RPX1NDVFApIGNhbGwgYXV0by1sb2FkcyBTQ1RQIG1vZHVsZS4gQnV0IHRv
IGJlIGhvbmVzdCwgSSdkDQo+IGJlIHN1cnByaXNlZCBpZiBDbG91ZCBwcm92aWRlcnMgYWxsb3cg
Zm9yIHRoaXMuIE1vc3Qgb2YgdGhpcyBtaWdodCBvbmx5IHJ1bg0KPiBvbiBkZWRpY2F0ZWQgYm94
ZXMgd2l0aCB0ZWxjbyBhcHBsaWFuY2VzLg0KDQpZZXMsIEknbSB3b3JyaWVkIGFib3V0IHdoZXRo
ZXIgb3VyIE0zVUEgY29kZSBpcyBsaWtlbHkgdG8gY3Jhc2ggY3VzdG9tZXINCnN5c3RlbXMsIG5v
dCB3aGV0aGVyIGhvc3RpbGUgYXBwbGljYXRpb25zIGNhbiBjcmFzaCBpdC4NClRoZXNlIGJveGVz
IG91Z2h0IHRvIGJlIG9uIHByaXZhdGUgbmV0d29ya3Mgc2luY2UgdGhlIHNpZ3RyYW4gcHJvdG9j
b2xzDQp0aGVtc2VsdmVzIGhhdmUgbm90aGluZyB0aGF0IGV2ZW4gZ2l2ZXMgYSBoaW50IG9mIHNl
Y3VyaXR5Lg0KDQoJRGF2aWQNCg=

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-10 12:26                     ` David Laight
@ 2015-12-10 15:58                       ` Eric Dumazet
  -1 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-10 15:58 UTC (permalink / raw)
  To: David Laight
  Cc: 'Daniel Borkmann',
	Marcelo Ricardo Leitner, Eric Dumazet, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Thu, 2015-12-10 at 12:26 +0000, David Laight wrote:

> Yes, I'm worried about whether our M3UA code is likely to crash customer
> systems, not whether hostile applications can crash it.
> These boxes ought to be on private networks since the sigtran protocols
> themselves have nothing that even gives a hint of security.

As long as the listener socket is kept as is, meaning that the only use
of it is the poll()/select()/accept() system calls, you are safe.

The bug is about having a fuzzer, specifically playing games with multi
threads so that the listener ipv6 options are changed after accept(). 

This should not really happen in real world applications : If ipv6
options need to be set on listener, they are set before first accept()
is performed, and not unset until application exits and kill all
sessions.

BTW, are you even using IPv6 SCTP sessions ?




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-10 15:58                       ` Eric Dumazet
  0 siblings, 0 replies; 34+ messages in thread
From: Eric Dumazet @ 2015-12-10 15:58 UTC (permalink / raw)
  To: David Laight
  Cc: 'Daniel Borkmann',
	Marcelo Ricardo Leitner, Eric Dumazet, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

On Thu, 2015-12-10 at 12:26 +0000, David Laight wrote:

> Yes, I'm worried about whether our M3UA code is likely to crash customer
> systems, not whether hostile applications can crash it.
> These boxes ought to be on private networks since the sigtran protocols
> themselves have nothing that even gives a hint of security.

As long as the listener socket is kept as is, meaning that the only use
of it is the poll()/select()/accept() system calls, you are safe.

The bug is about having a fuzzer, specifically playing games with multi
threads so that the listener ipv6 options are changed after accept(). 

This should not really happen in real world applications : If ipv6
options need to be set on listener, they are set before first accept()
is performed, and not unset until application exits and kill all
sessions.

BTW, are you even using IPv6 SCTP sessions ?




^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-10 15:58                       ` Eric Dumazet
  (?)
@ 2015-12-10 17:27                         ` David Laight
  -1 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-10 17:27 UTC (permalink / raw)
  To: 'Eric Dumazet'
  Cc: 'Daniel Borkmann',
	Marcelo Ricardo Leitner, Eric Dumazet, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 847 bytes --]

From: Eric Dumazet
> Sent: 10 December 2015 15:58
>
> BTW, are you even using IPv6 SCTP sessions ?

Our M3UA/SCTP protocol stack supports them and defaults to using
IPv6 listening sockets for IPv4 connections.

I very much doubt than any customers have used them yet.
So most of the IPv6 connections will have been to ::1
during internal regression testing.

We don't even try to set any IPv6 (or IPv4) options.

Just SO_REUSEADDR, TCP/SCTP_NODELAY, SCTP_EVENTS, SCTP_INITMSG,
SO_KEEPALIVE (tcp), IPV6_V6ONLY (if binding separate listeners),
SCTP_SOCKOPT_BINX_ADD (WTF is this a 'socket option') and
SO_LINGER (to get abortive close on SCTP connections on kernels
before 3.18).

	David

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-10 17:27                         ` David Laight
  0 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-10 17:27 UTC (permalink / raw)
  To: 'Eric Dumazet'
  Cc: 'Daniel Borkmann',
	Marcelo Ricardo Leitner, Eric Dumazet, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

From: Eric Dumazet
> Sent: 10 December 2015 15:58
>
> BTW, are you even using IPv6 SCTP sessions ?

Our M3UA/SCTP protocol stack supports them and defaults to using
IPv6 listening sockets for IPv4 connections.

I very much doubt than any customers have used them yet.
So most of the IPv6 connections will have been to ::1
during internal regression testing.

We don't even try to set any IPv6 (or IPv4) options.

Just SO_REUSEADDR, TCP/SCTP_NODELAY, SCTP_EVENTS, SCTP_INITMSG,
SO_KEEPALIVE (tcp), IPV6_V6ONLY (if binding separate listeners),
SCTP_SOCKOPT_BINX_ADD (WTF is this a 'socket option') and
SO_LINGER (to get abortive close on SCTP connections on kernels
before 3.18).

	David


^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-10 17:27                         ` David Laight
  0 siblings, 0 replies; 34+ messages in thread
From: David Laight @ 2015-12-10 17:27 UTC (permalink / raw)
  To: 'Eric Dumazet'
  Cc: 'Daniel Borkmann',
	Marcelo Ricardo Leitner, Eric Dumazet, Dmitry Vyukov,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Vlad Yasevich,
	Neil Horman, linux-sctp, syzkaller, Kostya Serebryany,
	Alexander Potapenko, Sasha Levin

RnJvbTogRXJpYyBEdW1hemV0DQo+IFNlbnQ6IDEwIERlY2VtYmVyIDIwMTUgMTU6NTgNCj4NCj4g
QlRXLCBhcmUgeW91IGV2ZW4gdXNpbmcgSVB2NiBTQ1RQIHNlc3Npb25zID8NCg0KT3VyIE0zVUEv
U0NUUCBwcm90b2NvbCBzdGFjayBzdXBwb3J0cyB0aGVtIGFuZCBkZWZhdWx0cyB0byB1c2luZw0K
SVB2NiBsaXN0ZW5pbmcgc29ja2V0cyBmb3IgSVB2NCBjb25uZWN0aW9ucy4NCg0KSSB2ZXJ5IG11
Y2ggZG91YnQgdGhhbiBhbnkgY3VzdG9tZXJzIGhhdmUgdXNlZCB0aGVtIHlldC4NClNvIG1vc3Qg
b2YgdGhlIElQdjYgY29ubmVjdGlvbnMgd2lsbCBoYXZlIGJlZW4gdG8gOjoxDQpkdXJpbmcgaW50
ZXJuYWwgcmVncmVzc2lvbiB0ZXN0aW5nLg0KDQpXZSBkb24ndCBldmVuIHRyeSB0byBzZXQgYW55
IElQdjYgKG9yIElQdjQpIG9wdGlvbnMuDQoNCkp1c3QgU09fUkVVU0VBRERSLCBUQ1AvU0NUUF9O
T0RFTEFZLCBTQ1RQX0VWRU5UUywgU0NUUF9JTklUTVNHLA0KU09fS0VFUEFMSVZFICh0Y3ApLCBJ
UFY2X1Y2T05MWSAoaWYgYmluZGluZyBzZXBhcmF0ZSBsaXN0ZW5lcnMpLA0KU0NUUF9TT0NLT1BU
X0JJTlhfQUREIChXVEYgaXMgdGhpcyBhICdzb2NrZXQgb3B0aW9uJykgYW5kDQpTT19MSU5HRVIg
KHRvIGdldCBhYm9ydGl2ZSBjbG9zZSBvbiBTQ1RQIGNvbm5lY3Rpb25zIG9uIGtlcm5lbHMNCmJl
Zm9yZSAzLjE4KS4NCg0KCURhdmlkDQoNCg=

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
  2015-12-09 15:25         ` Eric Dumazet
@ 2015-12-12  1:19           ` David Miller
  -1 siblings, 0 replies; 34+ messages in thread
From: David Miller @ 2015-12-12  1:19 UTC (permalink / raw)
  To: eric.dumazet
  Cc: edumazet, marcelo.leitner, dvyukov, kuznet, jmorris, yoshfuji,
	kaber, netdev, linux-kernel, vyasevich, nhorman, linux-sctp,
	syzkaller, kcc, glider, sasha.levin

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 09 Dec 2015 07:25:06 -0800

> From: Eric Dumazet <edumazet@google.com>
> 
> SCTP is lacking proper np->opt cloning at accept() time.
> 
> TCP and DCCP use ipv6_dup_options() helper, do the same
> in SCTP.
> 
> We might later factorize this code in a common helper to avoid
> future mistakes.
> 
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
@ 2015-12-12  1:19           ` David Miller
  0 siblings, 0 replies; 34+ messages in thread
From: David Miller @ 2015-12-12  1:19 UTC (permalink / raw)
  To: eric.dumazet
  Cc: edumazet, marcelo.leitner, dvyukov, kuznet, jmorris, yoshfuji,
	kaber, netdev, linux-kernel, vyasevich, nhorman, linux-sctp,
	syzkaller, kcc, glider, sasha.levin

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 09 Dec 2015 07:25:06 -0800

> From: Eric Dumazet <edumazet@google.com>
> 
> SCTP is lacking proper np->opt cloning at accept() time.
> 
> TCP and DCCP use ipv6_dup_options() helper, do the same
> in SCTP.
> 
> We might later factorize this code in a common helper to avoid
> future mistakes.
> 
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2015-12-12  1:19 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-09 14:15 use-after-free in inet6_destroy_sock Dmitry Vyukov
2015-12-09 14:15 ` Dmitry Vyukov
2015-12-09 14:43 ` Eric Dumazet
2015-12-09 14:43   ` Eric Dumazet
2015-12-09 14:59   ` Marcelo Ricardo Leitner
2015-12-09 14:59     ` Marcelo Ricardo Leitner
2015-12-09 15:09     ` Eric Dumazet
2015-12-09 15:09       ` Eric Dumazet
2015-12-09 15:25       ` [PATCH net] ipv6: sctp: clone options to avoid use after free Eric Dumazet
2015-12-09 15:25         ` Eric Dumazet
2015-12-09 15:34         ` Vlad Yasevich
2015-12-09 15:34           ` Vlad Yasevich
2015-12-09 15:49         ` David Laight
2015-12-09 15:49           ` David Laight
2015-12-09 15:49           ` David Laight
2015-12-09 15:59           ` Eric Dumazet
2015-12-09 15:59             ` Eric Dumazet
2015-12-09 16:31             ` David Laight
2015-12-09 16:31               ` David Laight
2015-12-09 16:31               ` David Laight
2015-12-09 17:11               ` Marcelo Ricardo Leitner
2015-12-09 17:11                 ` Marcelo Ricardo Leitner
2015-12-09 19:19                 ` Daniel Borkmann
2015-12-09 19:19                   ` Daniel Borkmann
2015-12-10 12:26                   ` David Laight
2015-12-10 12:26                     ` David Laight
2015-12-10 12:26                     ` David Laight
2015-12-10 15:58                     ` Eric Dumazet
2015-12-10 15:58                       ` Eric Dumazet
2015-12-10 17:27                       ` David Laight
2015-12-10 17:27                         ` David Laight
2015-12-10 17:27                         ` David Laight
2015-12-12  1:19         ` David Miller
2015-12-12  1:19           ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.