Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

[Xin Long]

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.
But there seems a case to cause a use-after-free when out of snd_buf.

the case is like:
-----------
one thread:                       another thread:
                                  sctp_rcv hold asoc (hold transport)
                                  enqueue the chunk to backlog queue
                                  [refcnt=2]

sctp_close free assoc
[refcnt=1]

sctp_sendmsg find asoc
but not hold it

out of snd_buf
hold asoc, schedule out
[refcnt = 2]

                                  process backlog and put asoc/transport
                                  [refcnt=1]

schedule in, put asoc
[refcnt=0] <--- destroyed

sctp_sendmsg continue
using asoc, panic

--------------------

Maybe we should check if asoc is dead already when schedule back
into sctp_sendmsg because of out of snd_buf.

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

[Marcelo Ricardo Leitner]

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.

> But there seems a case to cause a use-after-free when out of snd_buf.
> 
> the case is like:
> -----------
> one thread:                       another thread:
>                                   sctp_rcv hold asoc (hold transport)
>                                   enqueue the chunk to backlog queue
>                                   [refcnt=2]
> 
> sctp_close free assoc
> [refcnt=1]
> 
> sctp_sendmsg find asoc
> but not hold it
> 
> out of snd_buf
> hold asoc, schedule out
> [refcnt = 2]
> 
>                                   process backlog and put asoc/transport
>                                   [refcnt=1]
> 
> schedule in, put asoc
> [refcnt=0] <--- destroyed
> 
> sctp_sendmsg continue

It shouldn't be continuing here because sctp_wait_for_sndbuf and
sctp_wait_for_connect functions are checking if the asoc is dead
already when it schedules in, even though sctp_wait_for_connect return
value is ignored and sctp_sendmsg() simply returns after that.
Or the checks for dead asocs in there aren't enough somehow.

> using asoc, panic

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

[Xin Long]

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 ?

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

[Marcelo Ricardo Leitner]

On Wed, Apr 05, 2017 at 06:48:45PM +0800, Xin Long wrote:
> 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.

Yes. That explains why the asoc isn't dead by when sendmsg comes back,
and avoid that dead check.

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

Agreed.

> 
> 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 ?

Yes, agreed.
Thanks!

  Marcelo

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

[Andrey Konovalov]

[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]

On Tue, Apr 4, 2017 at 11:14 PM, 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.

We do have some plans (like to remote all those unnecessary helper
functions), but it's probably not going to become much better.

You mostly only need to look at the thr() function to understand
what's going on.

What I sometimes do is run each of the switch cases under strace
separately to understand what each of them do.

I've also attached a program in syzkaller format.
You can take a look at it, if you find it useful, I can start
attaching them for subsequent reports.

>
>> But there seems a case to cause a use-after-free when out of snd_buf.
>>
>> the case is like:
>> -----------
>> one thread:                       another thread:
>>                                   sctp_rcv hold asoc (hold transport)
>>                                   enqueue the chunk to backlog queue
>>                                   [refcnt=2]
>>
>> sctp_close free assoc
>> [refcnt=1]
>>
>> sctp_sendmsg find asoc
>> but not hold it
>>
>> out of snd_buf
>> hold asoc, schedule out
>> [refcnt = 2]
>>
>>                                   process backlog and put asoc/transport
>>                                   [refcnt=1]
>>
>> schedule in, put asoc
>> [refcnt=0] <--- destroyed
>>
>> sctp_sendmsg continue
>
> It shouldn't be continuing here because sctp_wait_for_sndbuf and
> sctp_wait_for_connect functions are checking if the asoc is dead
> already when it schedules in, even though sctp_wait_for_connect return
> value is ignored and sctp_sendmsg() simply returns after that.
> Or the checks for dead asocs in there aren't enough somehow.
>
>> using asoc, panic
>
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: log --]
[-- Type: application/octet-stream, Size: 9189 bytes --]

mmap(&(0x7f0000000000/0x482000)=nil, (0x482000), 0x3, 0x10000000000032, 0xffffffffffffffff, 0x0)
r0 = socket$sctp(0x2, 0x1, 0x84)
setsockopt$sock_int(r0, 0x1, 0x20, &(0x7f000047c000)=0x849, 0x4)
bind$sctp(r0, &(0x7f0000001000-0x10)=@in={0x2, 0x0, @loopback=0x7f000001, [0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0]}, 0x10)
sendto$sctp(r0, &(0x7f0000477000)="90703d6b7b328d74cc", 0x9, 0x0, &(0x7f0000477000)=@in={0x2, 0x0, @loopback=0x7f000001, [0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0]}, 0x10)
sendto$sctp(r0, &(0x7f000047a000)="99212019d215dacdd21f1d334726a669ecbb9e5d62b0ad2ddf0138d9d86050f6a0ed17d9da9a973700bd6bc9307ecb6fe6d4b62b090f7c0d6345ae24e4caf3b018701d0371307462e113268c6a09d632fdc05aec0a4dc0ca1c37ea72c9ff65dd1ac307f766a5b3e9179d4d1f8712535b5f0b5940b05f99139c600129b8397c67e550a736b682896086d34e436631972c0e735dec9c9bdd8dba4fa984237f513529d68b75efc8bf635de300f60582b733c6f19f5fc4df250167f748337f74fe7828f5fbf202adc3686fd1acf1bbcbd11b3a9b8e6ccd4e2e9e653492d6227399646265e91a0d052ff7703d409acffa404f6a7e5b12b77c87c7f648001b59d6877ae74d7763023eaca2c3e37c35406fc23bc5679cf3b0c65636567bbd7a37582b93eef6a190add733894decf59c74423531db0c9ca80c320e1a728e4f78675cf2a96abf58dfce7b08a1b80735ee32f4c32ab9613cfb28a32be941a5ebf88420036c577c81181e46a465eab3a5c4fb65f46ff5bb7ab42c6c24b07da037e98360be14911c7d12fd073ddfc9296fa4936a6a2860aad857afeaa305d42d83f174ac63e67f25c84cb1b9bd3ea476abc31cfbd9273c72d2777590394ebfe96d6fe50504985a0c386dbbf20a7cb9285dacfc26d2ef1e72cbc0c9b2bb9615c0ed3f2ebebdb8cc79a10a95c5f5cca45f8cf1f5f6a0478c0f70ab09ebf75c92c0dc25980fcf52f826dc8aa35b946369369fb7ab56e7570e2c4db55ae33b438f789771e0e59c6c922adc47e3016e01549d531124eabcab116abcfd1e8f037c708afd8242d0b9031c2d7fe083132eaa5095a96e0075b272027dc4b45ae7eed0ae4832650fd5215d4bda7b0e100370fe095ed8331f2b8af028f6dae3c9cc748466228c7d254b5b955c0d95554fc4a4256de96967674fd0a5e9474887217a14a025784d536f861a82997ead4a87244d8518fbb9edfa4adf60a7da11d2997283da768fe975c382d9f3ea4469381d287951ec0d08f581386164a4b34de9cc5506a7ddba5215e6798db83fc5a981435213426a63035371c5ebcc2c2a663da57253af1b4de3b070462bca1d17856074c84f544093b7e2a74f4395439886a06ac95cfb5bb26a1e2baace104c0a1f4f631d4bab143b6a523cb200d7072197aa9511a0d336e7747685bd4f1f10fb85ca034d8774b9b125cc7c821f24817840375c0bdb25f251b0034587ef99bf79e1c6f20789b2b32b7e72d5d110e6c4e8cd2cd5673ac77ac6d9108b4abf78e6c98787bbfc56c1715bbe01bf5a7c36a1f9b5a1875ede17b4bc61d1c35af83a65412616022a1bcca75a67804732b1d4e4d579d6eeb30e8e2b04f43e0efeb737dd28f230183ed76d8d1b53e4dab7f1cfaf65f896a542d8f7f223f68c55404df28121c64af00934cfd04c5fe68050a2ee63181c596be758e86fed547800d4ab6bf1f47717f763b1f725c71100ac4a6d683cf08ffaf0ae170e3eae029ce7abe89da17c05429375451524b85e6745fe99ed8318cae8021fb4606c017b9911fa6bcd50a92b2c6f8add4432c3d8696c2605db2e81a68eb5faa91a3495d6bedb4bd5174a5e02e392f16e445b92095c592ddffec60c2e3caa2e4a182b4b9d5e57723da311a12fb02d43698f65ced8fdfb48f5d0e3a2c7a517be78c64c6edd00d1795e996421d938b5b5082fac5d2b624676ccfab82af681fef1fbc915d9c07655688ffdae5fe38ada5fb217ec0337136999eedf2db80bbcfc8dc33e9019997830364d4edc45ba485a4a6846e05c8b5edc26e63739c9a8e8c404aa59481e9fcf6d9ad33b6c1163a47eb96c71e328db4fc2df35524502c6108a7a3d27870e3cd482853d58aca628ac2269ff041b46a384d548108c51ee65d297991c22d076ce44e0d2b7d9b32c990e3b15611ec47055ec5efcc697f7b7e6d19fc339f992167348af98f022f2b3e11a57054feaadeb777d0e1fe019afd0ff6dadefeccaf7c5b03406283d2c08e55c9259f5da5f54969ed910584945c4a94bc4c2cd169f77d9445ebb4a6706cb686ccaf29e333177723a5a83f09de011a558364390dbfb815d6170ea36108c749af0e98888a4aff5934b9548654f54e57b8bb9f215262cdec514c35e2811d4a9b540c6b8524f34994e1b59d3ad6def4791e741a639611c03422e4fb9d4604c785fe0ab13e0d151b4af9ee7011e6fb711e6e851588c479775d867e94d7a16127a3832df4f61e8cb43daf3178c7454edbea53dceeffb61f22812d3f9c5223a91ad183956dbcc69ed6f305c4e9482c01af2cf8605f593fdd00c19e856c00a67b78b6ecede3551bb5fc0a31720921d002d1382add1c86e138d98af885e29f6bc8295b51292e3f2041083552cf633a015c044d3ce5eb10d564661d02fafd47b2599eeefd5bb4fa01149634f42b184c025958772f722c59cb867c74e3016a55808e73e1488ea27b2d5368d8ab9bb9dca35d699a2d69a17d3a1cffa92f2a307860961f6142cb9fc5ba58cfbb6c30f0b53f8f576705a578531199ba2774fecd23146d11021ca9cf7ae680e7a2ea574c586cf19766fe1df9d0ea9e72b7426f450911b1d16f471c2b00aa4339badecd0823b5944cb86f42f6c139f78e5dc53234ddac2313278ed97185741414eb370af1fac59735a5600fd5b8626b20c0effcae968be2d2b557405bf6204e1f9e768aa35f55dadba517f58587378426efc7899a6d076acd43c2fd03bc8722fd33c345da739820e71fb87aa2cff15d587519a0dc8ea79c9eddee10974122c1ab6b7bc8eac9a131d50d5c1757e8999a460d798f24975e31849698c4e27148766533ecc3f368672b8b83d8235d9147dccfc3ebfc0e3dbf63dbbf5353090f133f665986c02fb50cbcd0a41d9ee8713fb1c653f157e59725ac45de33a4df6b862910eddd2d2dd6f11587669580e2cd2a9ea6bdb9f90abd51243b367586a6741bd9f7b76096e599fe60099a2ad63d8d73783f9b0714af9941002f90b4cac81bb4739c7003526d0bac90ac219ba94d17a7344847c03298480f8d2d33b0214dd2dd7da61aaf601e8581fcf1414a7cc9206f97aba60d1b5254c08d7e5ed30cfba413ebc1c6214050dfbbe3452110a1ecb9cbb9a41a735fa80e1ca3026aa52637696ed8506e49f2f9089046b9874e4d69d72e338349e0d7d9814529e8c1fb3f6c63ae9594777f72b0f49a3f69af73a55bd3ba11f16db9df536f209076dcbd06528de2400222934f260f99c3a108954e63de73894c69548407e21eababde0fd288e995d5e6ba8f1993f7f08e236550600eaae1f29df3ef4782be557506cff537fc10109377525973d5ae0acabe68a01703d0810b8326d1911f46300dc15c55baabf7d63323abcbf7d9ef28987735463d1dd9b57eab116ec0857178cd92c8db5b1423a88ee7329f1c8af54996f42b51a9f228714024e879e4693047636c485d757d6363a9528a63154f17e90d35ed91c9de25aba2398708561dfd02cf0ac3fa923750dde094eb25654a6da55258627a8aee99c48f99406ae88974eb730c10d79a338a254dc1f9c494272f5c10df00c780c693f7c5756c0119dfb86f67732cac7761e2f6a755b4a38442fb9017a03f575fd643eb4ac51bc36fddddac28919f293c8f86902ee4b8223f4db913f3b907f557cb1283dbd35049a3a0e2297524bc3a32d1471147268ab7e2afe9d9e0f8eee352d943ecd057534e57a18501e68a11bba926270fe76509e701561c0310b1eeeb4e3bdbb99c9724f3b19f0f8b6e76aaea1598a402c65c883e9c977696f0243849be184ec24f4ca12b99c9ec2984dd69a1f81e0e0278f7958f5f8e679050fd872e9af2f0eb933459af12be901818adfaa859d592a938123ce96561ba8daee0a66d47b9de952628651dcdad49fac2961883b86dbc176a9a48a0897e1b71ecb4468d90baa321d0e3df1516e8e7bcda6fa21db334ea7fb99b96ac61f98baba48893de89312d9caac1c9144b925fae927245558ec9352c3bb90f1ecc686e1455bfefec8303bdba2368d58ffbc082e30cb5a44751cb69a8185352d2faa84b119324986196069b6912a4e05a1b41d08a50cdb5f535e0cb93eef2ea9274674b48b2ff1f502f8799a05c40b99dfee364b7beeeb1b17427c1b1a057163e87a98f8dbed3d71ae8b07a96a0ca4bdfb14afcfbadc0296045ce38d249919614f147d4a6d7ed7d80a5d8af19859fd9369ea5be7561bd5341da92c9240f3f005178f1d7388f4de427c6339b015459810d6ee6da782067bc01817b525d7c58c781a8b2e6e0eeede7b285e0ef0c3c53143d19b9c57ede3511bc0b042e4c745b56f4542ed1f4e2b7f16bebe8d08cb94093fcca5efc5ab668833605ea0f1e3195e73e5ea937b1f704fcd044188dc4b57c13e7a83153d12076877a101d38fb8c1d2d79b72b2c93b20d7d350df5c32f2d84546cb2b307b294bfc10fc3790d42cec75874ad06d1f82a801505db89cc0658fac64a60420363ea52185befb627b8950472f8dbb8075860b6e4198c96abad850090c9ef79d304a27b0e09ec2fd1c1cd2b722e8fab14edf49ca37c4989ab09399ceffdb68649bb30e9a926a6dce8867e9f86da8cbab8cf275098917db64c65cb3432c1e0788d45bf3a2809b06a36516dec881d94d58dcaac58b17a19c03d91aa1d74614b94dc6bbe489fefd083f357f3d1e273bb715a166c6563bcbefbefc180de0a69a2f446fa92dd605b418e9208aee629f95e74ecab4b5cd5caefd48f254696b3a4eba8a40a480f98a53df02ff86f0e2c9d65b3b3409576f42834c33f09df6b3234629ed80703541b3069e8658cbac430b6564e5ebc3b289e5a30f115b80487eba406fcb5747a7fe593cf00b607cf581982b2de666923ca3e9b6f9d604b117a947ec96e9b041e14fe35d4e63ec3f0e7d38b722a9b66394adc94108788e476bd859d70502575abaa81e96d151d8a0c143f5454f1cefcaa5049d8ae407d34d7383d75cdf17267bde9021cc94f67fcbcd172ba7b70063c19864510ca3b00e71ba9bc496891c12b8ac5c8f73842a28733303275a9204bb4593bd945b87fad88e7dd08811979f6bbc3bfb74e4f882fff00912f735b8a2cd6487705368edc9fe6623fe388e038fd1d13075e573632320b7e0e185c67c29982f83fc21e961cfc6c5b733b36472b228185a7330f2c530fb365266f96633483cacef4b007293a751ecd5eb0fb1552990514ce5e9444400f475dfbc64a5d3ebebc79674029bc5cd56b83d34fb1c406bf86dfab445eb89898fc683ee44ba9e6024d019b5a0c2ba8156c585544863e89dd20260a4aa01d1dca47abcf2222a442585ff5b0b05d73392b7684c26eafa65865a94ec2ac298ec5f912494a31193dc559e31e91f29ea374ecfcfd5dab62344e84b8a7278031309c0cde029dd83bf48d7fb5b83e421280e35bdc14133de8fbf2eb7cae0252801291062c287ea7953bc2492e0c6c5134f49bedeb3333531febd8cfdc007080b590c53dfdc2ea4d886e6e03a975c471782773d3dc28f27f63e1443e47db881f92a28974f04e3de6e6b7a1319ef6e963e1fb1c1480816f80128aaa3f26a82f400185bb431404f7581f7001fdd451fa994e78c36555ee01a0a1e2f13906cc121c8e29ec553469a060b5757757450dd3d37911e79268679a7346ea71ed05a12ccbb3e49134d020990baad49d361858b4648ba132d5cedf9763292f59b6c2dfeb447f6e2930eaceae45217e0cc189738d6e0bc6ff011a9cddc8fa77c8d968081cd7d774e248edd4c0d91d8ccfb4cdf383cba0c8c970738b983b489c29f31b604", 0x1000, 0x20004000, 0x0, 0x0)
sendmsg$sctp(r0, &(0x7f000047a000)={&(0x7f000047a000)=@in={0x2, 0x0, @empty=0x0, [0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0]}, 0x10, &(0x7f000047b000-0x20)=[{&(0x7f000032d000-0x44)="9ac52b7d1d3765f94f3e01dcc0e6e465b6bfb4817f29bda256e98c4223db73b880e1", 0x22}], 0x1, 0x0, 0x0, 0x0}, 0x4000)
mmap(&(0x7f00001ff000/0x800000)=nil, (0x800000), 0x5, 0x32, r0, 0x0)
listen(r0, 0x7fff)
accept$sctp(r0, &(0x7f00003ad000-0x1)=nil, &(0x7f000047b000)=0x0)

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

[Andrey Konovalov]

On Wed, Apr 5, 2017 at 2:44 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Apr 05, 2017 at 06:48:45PM +0800, Xin Long wrote:
>> 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.
>
> Yes. That explains why the asoc isn't dead by when sendmsg comes back,
> and avoid that dead check.
>
>>
>> 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.
>
> Agreed.
>
>>
>> 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;
>> +

This fixes the report.

Tested-by: Andrey Konovalov <andreyknvl@google.com>

Thanks!

>>
>> what do you think ?
>
> Yes, agreed.
> Thanks!
>
>   Marcelo

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

[Marcelo Ricardo Leitner]

On Wed, Apr 05, 2017 at 04:02:44PM +0200, Andrey Konovalov wrote:
> On Tue, Apr 4, 2017 at 11:14 PM, 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.
> 
> We do have some plans (like to remote all those unnecessary helper
> functions), but it's probably not going to become much better.
> 
> You mostly only need to look at the thr() function to understand
> what's going on.

Okay.

> 
> What I sometimes do is run each of the switch cases under strace
> separately to understand what each of them do.
> 
> I've also attached a program in syzkaller format.
> You can take a look at it, if you find it useful, I can start
> attaching them for subsequent reports.

Comparing it to thr() they look very close, at least for this one.
But when you cannot extract a reproducer, it will certainly help.

Thanks,
Marcelo