use-after-free in inet6_destroy_sock

[Dmitry Vyukov]

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.

[Eric Dumazet]

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 ?

[Marcelo Ricardo Leitner]

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

[Eric Dumazet]

I'll cook it right now, no worries.

Thanks.

[Eric Dumazet]

From: Eric Dumazet <edum...@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 <dvy...@google.com>
Signed-off-by: Eric Dumazet <edum...@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().
*/

[Vlad Yasevich]

On 12/09/2015 10:25 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edum...@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 <dvy...@google.com>
> Signed-off-by: Eric Dumazet <edum...@google.com>

Acked-by: Vlad Yasevich <vyas...@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

[David Laight]

> 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

[Eric Dumazet]

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.

[David Laight]

From: Eric Dumazet [mailto:eric.d...@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

[Marcelo Ricardo Leitner]

Em 09-12-2015 14:31, David Laight escreveu:
> From: Eric Dumazet [mailto:eric.d...@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

[Daniel Borkmann]

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.d...@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.

[David Laight]

From: Daniel Borkmann
> Sent: 09 December 2015 19:19

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

[Eric Dumazet]

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 ?

[David Laight]

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

[David Miller]

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

> From: Eric Dumazet <edum...@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 <dvy...@google.com>
> Signed-off-by: Eric Dumazet <edum...@google.com>

Applied and queued up for -stable, thanks.