From: Vlad Yasevich <vyasevich@gmail.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
"David S. Miller" <davem@davemloft.net>,
linux-sctp@vger.kernel.org, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Eric Dumazet <edumazet@google.com>,
syzkaller <syzkaller@googlegroups.com>,
Kostya Serebryany <kcc@google.com>,
Alexander Potapenko <glider@google.com>,
Sasha Levin <sasha.levin@oracle.com>
Subject: Re: net/sctp: use-after-free in __sctp_connect
Date: Tue, 19 Jan 2016 14:38:54 +0000 [thread overview]
Message-ID: <569E4A7E.4080301@gmail.com> (raw)
In-Reply-To: <20160115190106.GG6074@mrl.redhat.com>
On 01/15/2016 02:01 PM, Marcelo Ricardo Leitner wrote:
> On Wed, Jan 13, 2016 at 10:52:31AM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program causes use-after-free in __sctp_connect:
>>
> ...
>> INFO: Freed in sctp_association_put+0x150/0x250 age=0 cpu=3 pid\x15267
>> [< none >] __slab_free+0x1fc/0x320 mm/slub.c:2678
>> [< inline >] slab_free mm/slub.c:2833
>> [< none >] kfree+0x2a8/0x2d0 mm/slub.c:3662
>> [< inline >] sctp_association_destroy net/sctp/associola.c:424
>> [< none >] sctp_association_put+0x150/0x250 net/sctp/associola.c:860
>> [< none >] sctp_wait_for_connect+0x37c/0x4f0 net/sctp/socket.c:7067
> ^^^^^^^^^^^^^^
>> [< none >] __sctp_connect+0x905/0xb90 net/sctp/socket.c:1215
>> [< none >] __sctp_setsockopt_connectx+0x198/0x1d0
>> net/sctp/socket.c:1328
>> [< inline >] sctp_setsockopt_connectx net/sctp/socket.c:1360
>> [< none >] sctp_setsockopt+0x226/0x3630 net/sctp/socket.c:3728
>> [< none >] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2642
>> [< inline >] SYSC_setsockopt net/socket.c:1752
>> [< none >] SyS_setsockopt+0x158/0x240 net/socket.c:1731
>> [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a
>> arch/x86/entry/entry_64.S:185
>
> This one may sher some light on that other socket leak one, because the
> association shouldn't have been freed at that point.
> Now, how it managed to unbalance that refcnt, hmm...
>
The free may be a result of implicit close when the program ends. If the thread
is still waiting for connect to finish when the program ends, we may end up
in a situation when the association has been freed, but the ref held by wait_for_connect
prevents the destruction. When wait_for_connect finishes in puts the ref and
causes the destruction.
What I am guessing is happing is the wait_for_connect doesn't catch the error condition
correctly and thus __sctp_connect() doesn't think there was and error and references
the assoc which was just destroyed.
-vlad
WARNING: multiple messages have this Message-ID (diff)
From: Vlad Yasevich <vyasevich@gmail.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
"David S. Miller" <davem@davemloft.net>,
linux-sctp@vger.kernel.org, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Eric Dumazet <edumazet@google.com>,
syzkaller <syzkaller@googlegroups.com>,
Kostya Serebryany <kcc@google.com>,
Alexander Potapenko <glider@google.com>,
Sasha Levin <sasha.levin@oracle.com>
Subject: Re: net/sctp: use-after-free in __sctp_connect
Date: Tue, 19 Jan 2016 09:38:54 -0500 [thread overview]
Message-ID: <569E4A7E.4080301@gmail.com> (raw)
In-Reply-To: <20160115190106.GG6074@mrl.redhat.com>
On 01/15/2016 02:01 PM, Marcelo Ricardo Leitner wrote:
> On Wed, Jan 13, 2016 at 10:52:31AM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program causes use-after-free in __sctp_connect:
>>
> ...
>> INFO: Freed in sctp_association_put+0x150/0x250 age=0 cpu=3 pid=15267
>> [< none >] __slab_free+0x1fc/0x320 mm/slub.c:2678
>> [< inline >] slab_free mm/slub.c:2833
>> [< none >] kfree+0x2a8/0x2d0 mm/slub.c:3662
>> [< inline >] sctp_association_destroy net/sctp/associola.c:424
>> [< none >] sctp_association_put+0x150/0x250 net/sctp/associola.c:860
>> [< none >] sctp_wait_for_connect+0x37c/0x4f0 net/sctp/socket.c:7067
> ^^^^^^^^^^^^^^
>> [< none >] __sctp_connect+0x905/0xb90 net/sctp/socket.c:1215
>> [< none >] __sctp_setsockopt_connectx+0x198/0x1d0
>> net/sctp/socket.c:1328
>> [< inline >] sctp_setsockopt_connectx net/sctp/socket.c:1360
>> [< none >] sctp_setsockopt+0x226/0x3630 net/sctp/socket.c:3728
>> [< none >] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2642
>> [< inline >] SYSC_setsockopt net/socket.c:1752
>> [< none >] SyS_setsockopt+0x158/0x240 net/socket.c:1731
>> [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a
>> arch/x86/entry/entry_64.S:185
>
> This one may sher some light on that other socket leak one, because the
> association shouldn't have been freed at that point.
> Now, how it managed to unbalance that refcnt, hmm...
>
The free may be a result of implicit close when the program ends. If the thread
is still waiting for connect to finish when the program ends, we may end up
in a situation when the association has been freed, but the ref held by wait_for_connect
prevents the destruction. When wait_for_connect finishes in puts the ref and
causes the destruction.
What I am guessing is happing is the wait_for_connect doesn't catch the error condition
correctly and thus __sctp_connect() doesn't think there was and error and references
the assoc which was just destroyed.
-vlad
next prev parent reply other threads:[~2016-01-19 14:38 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 9:52 net/sctp: use-after-free in __sctp_connect Dmitry Vyukov
2016-01-13 9:52 ` Dmitry Vyukov
2016-01-14 1:37 ` YUAN Jia
2016-01-14 1:37 ` YUAN Jia
2016-01-14 1:45 ` Marcelo Ricardo Leitner
2016-01-14 1:45 ` Marcelo Ricardo Leitner
2016-01-15 19:01 ` Marcelo Ricardo Leitner
2016-01-15 19:01 ` Marcelo Ricardo Leitner
2016-01-19 14:38 ` Vlad Yasevich [this message]
2016-01-19 14:38 ` Vlad Yasevich
2016-01-21 17:18 ` Marcelo Ricardo Leitner
2016-01-21 17:18 ` Marcelo Ricardo Leitner
2016-01-21 17:37 ` Marcelo Ricardo Leitner
2016-01-21 17:37 ` Marcelo Ricardo Leitner
2016-10-19 12:25 ` Andrey Konovalov
2016-10-19 12:25 ` Andrey Konovalov
2016-10-19 16:57 ` Marcelo Ricardo Leitner
2016-10-19 16:57 ` Marcelo Ricardo Leitner
2016-11-02 22:42 ` Andrey Konovalov
2016-11-02 22:42 ` Andrey Konovalov
2016-11-03 17:11 ` Andrey Konovalov
2016-11-03 17:11 ` Andrey Konovalov
2016-11-03 17:52 ` Marcelo Ricardo Leitner
2016-11-03 17:52 ` Marcelo Ricardo Leitner
2016-11-03 18:02 ` Andrey Konovalov
2016-11-03 18:02 ` Andrey Konovalov
2016-11-03 18:35 ` Marcelo Ricardo Leitner
2016-11-03 18:35 ` Marcelo Ricardo Leitner
2016-11-03 18:45 ` Andrey Konovalov
2016-11-03 18:45 ` Andrey Konovalov
2016-11-04 12:59 ` Neil Horman
2016-11-04 12:59 ` Neil Horman
2016-11-04 13:03 ` Marcelo Ricardo Leitner
2016-11-04 13:03 ` Marcelo Ricardo Leitner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=569E4A7E.4080301@gmail.com \
--to=vyasevich@gmail.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=edumazet@google.com \
--cc=glider@google.com \
--cc=kcc@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=sasha.levin@oracle.com \
--cc=syzkaller@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.