Re: [PATCH 4.4 14/20] sctp: avoid BUG_ON on sctp_wait_for_sndbuf

From: Marcelo Ricardo Leitner
Date: Tue Feb 21 2017 - 14:54:50 EST


On Tue, Feb 21, 2017 at 1:56 PM, Marcelo <marcelo.leitner@xxxxxxxxx> wrote:
>
>
> Em 21 de fevereiro de 2017 13:08:44 BRT, Ben Hutchings <ben@xxxxxxxxxxxxxxx> escreveu:
>>On Thu, 2017-02-16 at 09:53 -0800, Greg Kroah-Hartman wrote:
>>> 4.4-stable review patch. If anyone has any objections, please let me
>>know.
>>>
>>> ------------------
>>>
>>> From: Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx>
>>>
>>>
>>> [ Upstream commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 ]
>>[...]
>>> --- a/net/sctp/socket.c
>>> +++ b/net/sctp/socket.c
>>> @@ -6960,7 +6960,8 @@ static int sctp_wait_for_sndbuf(struct s
>>> */
>>> release_sock(sk);
>>> current_timeo = schedule_timeout(current_timeo);
>>> - BUG_ON(sk != asoc->base.sk);
>>> + if (sk != asoc->base.sk)
>>> + goto do_error;
>>
>>This function normally returns with sk still locked, but in this case
>>it returns with sk unlocked. Perhaps this check should be moved after
>>the lock_sock(sk)?
>>
>
> Looks like so. Will check more in a few. Thanks Ben

Yes, we need to move the check to after the lock_sock(sk) call.

There is also another problem: consider a thread A sending a packet to
a new asoc (which creates a new asoc during sctp_sendsmg), and while
waiting for more sndbuf space, it gets peeled off by another thread.
This would cause a double-free of the asoc as sctp_sendmsg() will free
this asoc thinking it errored out but it actually now belongs to
another thread.

Testing both patches now, should be ready by tomorrow.

Marcelo

>
>>Ben.
>>
>>> lock_sock(sk);
>>>
>>> *timeo_p = current_timeo;
>>>
>>>
>
> --
> Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela brevidade.