Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1635738 > unrolled thread

Re: net/dccp: dccp_create_openreq_child freed held lock

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: net/dccp: dccp_create_openreq_child freed held lock Andrey Konovalov <andreyknvl@google.com> - 2017-05-04 15:40 +0200
    Re: net/dccp: dccp_create_openreq_child freed held lock Andrey Konovalov <andreyknvl@google.com> - 2017-05-04 16:00 +0200
    Re: net/dccp: dccp_create_openreq_child freed held lock David Miller <davem@davemloft.net> - 2017-05-04 16:20 +0200

#1635738 — Re: net/dccp: dccp_create_openreq_child freed held lock

On Wed, Mar 1, 2017 at 4:40 PM, Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
> Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu:
>> > Hello,
>> >
>> > I've got the following report while running syzkaller fuzzer on
>> > 86292b33d4b79ee03e2f43ea0381ef85f077c760:
>> >
>> >
>> > It seems that dccp_create_openreq_child needs to unlock the sock if
>> > dccp_feat_activate_values fails.
>>
>> Yeah, can you please use the patch below, that mimics the error paths in
>> sk_clone_new(), from where I think even the comment about it being a raw
>
> Argh, s/sk_clone_new()/sk_clone_lock()/g

Hi Arnaldo,

Could you send the patch?

We haven't seen these reports since we applied it.

Thanks!

>
> - Arnaldo
>
>> copy came, but the bh_unlock_sock() didn't?
>>
>> - Arnaldo
>>
>> diff --git a/net/dccp/minisocks.c b/net/dccp/minisocks.c
>> index 53eddf99e4f6..d20d948a98ed 100644
>> --- a/net/dccp/minisocks.c
>> +++ b/net/dccp/minisocks.c
>> @@ -122,6 +122,7 @@ struct sock *dccp_create_openreq_child(const struct sock *sk,
>>                       /* It is still raw copy of parent, so invalidate
>>                        * destructor and make plain sk_free() */
>>                       newsk->sk_destruct = NULL;
>> +                     bh_unlock_sock(newsk);
>>                       sk_free(newsk);
>>                       return NULL;
>>               }
>
> --
> 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.

[toc] | [next] | [standalone]

#1635745

On Thu, May 4, 2017 at 3:53 PM, David Miller <davem@davemloft.net> wrote:
> From: Andrey Konovalov <andreyknvl@google.com>
> Date: Thu, 4 May 2017 15:36:37 +0200
>
>> On Wed, Mar 1, 2017 at 4:40 PM, Arnaldo Carvalho de Melo
>> <acme@kernel.org> wrote:
>>> Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>> Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu:
>>>> > Hello,
>>>> >
>>>> > I've got the following report while running syzkaller fuzzer on
>>>> > 86292b33d4b79ee03e2f43ea0381ef85f077c760:
>>>> >
>>>> >
>>>> > It seems that dccp_create_openreq_child needs to unlock the sock if
>>>> > dccp_feat_activate_values fails.
>>>>
>>>> Yeah, can you please use the patch below, that mimics the error paths in
>>>> sk_clone_new(), from where I think even the comment about it being a raw
>>>
>>> Argh, s/sk_clone_new()/sk_clone_lock()/g
>>
>> Hi Arnaldo,
>>
>> Could you send the patch?
>>
>> We haven't seen these reports since we applied it.
>
> It isn't necessary in the current tree.
>
> Arnaldo created a helper sk_free_unlock_clone() which handles this situation
> properly, and calls it from dccp_create_openreq_child().

OK, great, thanks!

[toc] | [prev] | [next] | [standalone]

#1635775

From: Andrey Konovalov <andreyknvl@google.com>
Date: Thu, 4 May 2017 15:36:37 +0200

> On Wed, Mar 1, 2017 at 4:40 PM, Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
>> Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu:
>>> > Hello,
>>> >
>>> > I've got the following report while running syzkaller fuzzer on
>>> > 86292b33d4b79ee03e2f43ea0381ef85f077c760:
>>> >
>>> >
>>> > It seems that dccp_create_openreq_child needs to unlock the sock if
>>> > dccp_feat_activate_values fails.
>>>
>>> Yeah, can you please use the patch below, that mimics the error paths in
>>> sk_clone_new(), from where I think even the comment about it being a raw
>>
>> Argh, s/sk_clone_new()/sk_clone_lock()/g
> 
> Hi Arnaldo,
> 
> Could you send the patch?
> 
> We haven't seen these reports since we applied it.

It isn't necessary in the current tree.

Arnaldo created a helper sk_free_unlock_clone() which handles this situation
properly, and calls it from dccp_create_openreq_child().

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web