All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xin Long <lucien.xin@gmail.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
	Vlad Yasevich <vyasevich@gmail.com>,
	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>,
	Dmitry Vyukov <dvyukov@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Kostya Serebryany <kcc@google.com>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: net/sctp: list double add warning in sctp_endpoint_add_asoc
Date: Wed, 5 Apr 2017 18:48:45 +0800	[thread overview]
Message-ID: <CADvbK_dgD65mygqkGuA85ShBnHrD3y4u_P=XoREyEn7y0J4_+A@mail.gmail.com> (raw)
In-Reply-To: <20170404211454.GA911@localhost.localdomain>

On Wed, Apr 5, 2017 at 5:14 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Apr 05, 2017 at 01:29:19AM +0800, Xin Long wrote:
>> On Tue, Apr 4, 2017 at 9:28 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > Hi,
>> >
>> > I've got the following error report while fuzzing the kernel with syzkaller.
>> >
>> > On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5).
>> >
>> > A reproducer and .config are attached.
>> The script is pretty hard to reproduce the issue in my env.
>
> I didn't try running it but I also found the reproducer very complicated
> to follow. Do you have any plans on having some PoC optimizer, so we can
> have a more readable code?
> strace is handy for filtering the noise, yes, but sometimes it doesn't
> cut it.
I got the script now:
1. create sk
2. set sk->sndbuf = x
3. sendmsg with size s1 (s1 < x)
4. sendmsg with size s2 (s1+s2 > x)
5. sendmsg with size s3 (wspace < 0), wait sndbuf, schedule out.
6. listen sk (abnormal operation on sctp client)
7. accept sk.

In step 6, sk->sk_state = listening, then step 7 could get the first asoc
from ep->asoc_list and alloc a new sk2, attach the asoc to sk2.

after a while, sendmsg schedule in, but asoc->sk is sk2, !=sk.
the same issue we fix for peeloff on commit dfcb9f4f99f1 ("sctp: deny
peeloff operation on asocs with threads sleeping on it") happens.

But we should not fix it by the same way as for peeloff. the real reason
causes this issue is on step 6, it should disallow listen on the established sk.

The following fix should work for this, just similar with what
inet_listen() did.

@@ -7174,6 +7175,9 @@ int sctp_inet_listen(struct socket *sock, int backlog)
        if (sock->state != SS_UNCONNECTED)
                goto out;

+       if (!sctp_sstate(sk, LISTENING) && !sctp_sstate(sk,CLOSED))
+               goto out;
+

what do you think ?

WARNING: multiple messages have this Message-ID (diff)
From: Xin Long <lucien.xin@gmail.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
	Vlad Yasevich <vyasevich@gmail.com>,
	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>,
	Dmitry Vyukov <dvyukov@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Kostya Serebryany <kcc@google.com>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: net/sctp: list double add warning in sctp_endpoint_add_asoc
Date: Wed, 05 Apr 2017 10:48:45 +0000	[thread overview]
Message-ID: <CADvbK_dgD65mygqkGuA85ShBnHrD3y4u_P=XoREyEn7y0J4_+A@mail.gmail.com> (raw)
In-Reply-To: <20170404211454.GA911@localhost.localdomain>

On Wed, Apr 5, 2017 at 5:14 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Apr 05, 2017 at 01:29:19AM +0800, Xin Long wrote:
>> On Tue, Apr 4, 2017 at 9:28 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > Hi,
>> >
>> > I've got the following error report while fuzzing the kernel with syzkaller.
>> >
>> > On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5).
>> >
>> > A reproducer and .config are attached.
>> The script is pretty hard to reproduce the issue in my env.
>
> I didn't try running it but I also found the reproducer very complicated
> to follow. Do you have any plans on having some PoC optimizer, so we can
> have a more readable code?
> strace is handy for filtering the noise, yes, but sometimes it doesn't
> cut it.
I got the script now:
1. create sk
2. set sk->sndbuf = x
3. sendmsg with size s1 (s1 < x)
4. sendmsg with size s2 (s1+s2 > x)
5. sendmsg with size s3 (wspace < 0), wait sndbuf, schedule out.
6. listen sk (abnormal operation on sctp client)
7. accept sk.

In step 6, sk->sk_state = listening, then step 7 could get the first asoc
from ep->asoc_list and alloc a new sk2, attach the asoc to sk2.

after a while, sendmsg schedule in, but asoc->sk is sk2, !=sk.
the same issue we fix for peeloff on commit dfcb9f4f99f1 ("sctp: deny
peeloff operation on asocs with threads sleeping on it") happens.

But we should not fix it by the same way as for peeloff. the real reason
causes this issue is on step 6, it should disallow listen on the established sk.

The following fix should work for this, just similar with what
inet_listen() did.

@@ -7174,6 +7175,9 @@ int sctp_inet_listen(struct socket *sock, int backlog)
        if (sock->state != SS_UNCONNECTED)
                goto out;

+       if (!sctp_sstate(sk, LISTENING) && !sctp_sstate(sk,CLOSED))
+               goto out;
+

what do you think ?

  reply	other threads:[~2017-04-05 10:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-04 13:28 net/sctp: list double add warning in sctp_endpoint_add_asoc Andrey Konovalov
2017-04-04 17:29 ` Xin Long
2017-04-04 17:29   ` Xin Long
2017-04-04 21:14   ` Marcelo Ricardo Leitner
2017-04-04 21:14     ` Marcelo Ricardo Leitner
2017-04-05 10:48     ` Xin Long [this message]
2017-04-05 10:48       ` Xin Long
2017-04-05 12:44       ` Marcelo Ricardo Leitner
2017-04-05 12:44         ` Marcelo Ricardo Leitner
2017-04-05 14:03         ` Andrey Konovalov
2017-04-05 14:03           ` Andrey Konovalov
2017-04-05 14:02     ` Andrey Konovalov
2017-04-05 14:02       ` Andrey Konovalov
2017-04-05 14:22       ` Marcelo Ricardo Leitner
2017-04-05 14:22         ` 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='CADvbK_dgD65mygqkGuA85ShBnHrD3y4u_P=XoREyEn7y0J4_+A@mail.gmail.com' \
    --to=lucien.xin@gmail.com \
    --cc=andreyknvl@google.com \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=edumazet@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=syzkaller@googlegroups.com \
    --cc=vyasevich@gmail.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.