mbox series

[RFC,0/2] mptcp: fix deadlock in mptcp{,6}_release

Message ID cover.1614706783.git.pabeni@redhat.com
Headers show
Series mptcp: fix deadlock in mptcp{,6}_release | expand

Message

Paolo Abeni March 2, 2021, 5:47 p.m. UTC
This address the issue the easy way: removing the bugged feature
(mcast support :).

AFAICS the mcast related sockopt manipulate a global state, so there
could be existing working application doing setsockopt(mcast opt) on
TCP sockets. This is why I did not disable mcast at the inet level
for stream sockets.

Still I'm wondering if we should take the opposite approach: explicitly
forbitting all setsockopt except the one we implement in
net/mptcp/protocol.c

Additionally this possibly overlap with wider task - a more
comprehensive sockopt support. Ence the RFC tag.

Side note: syzbot confirm this fixes issues/170

Paolo Abeni (2):
  mptcp: forbit mcast-related sockopt on MPTCP sockets
  mptcp: revert "mptcp: provide subflow aware release function"$ ....$

 net/mptcp/protocol.c | 100 ++++++++++++++++++++-----------------------
 1 file changed, 47 insertions(+), 53 deletions(-)

Comments

Mat Martineau March 3, 2021, 1:56 a.m. UTC | #1
On Tue, 2 Mar 2021, Paolo Abeni wrote:

> This address the issue the easy way: removing the bugged feature
> (mcast support :).
>
> AFAICS the mcast related sockopt manipulate a global state, so there
> could be existing working application doing setsockopt(mcast opt) on
> TCP sockets. This is why I did not disable mcast at the inet level
> for stream sockets.
>
> Still I'm wondering if we should take the opposite approach: explicitly
> forbitting all setsockopt except the one we implement in
> net/mptcp/protocol.c
>

I think there was mailing list discussion about having an allowed list of 
SOL_TCP options, but I think applying that idea to the inet level slipped 
by. It does seem better to only allow the options we implement.

(by the way: it's forbid/forbidding)


Mat


> Additionally this possibly overlap with wider task - a more
> comprehensive sockopt support. Ence the RFC tag.
>
> Side note: syzbot confirm this fixes issues/170
>
> Paolo Abeni (2):
>  mptcp: forbit mcast-related sockopt on MPTCP sockets
>  mptcp: revert "mptcp: provide subflow aware release function"$ ....$
>
> net/mptcp/protocol.c | 100 ++++++++++++++++++++-----------------------
> 1 file changed, 47 insertions(+), 53 deletions(-)
>
> -- 
> 2.26.2
> _______________________________________________
> mptcp mailing list -- mptcp@lists.01.org
> To unsubscribe send an email to mptcp-leave@lists.01.org
>

--
Mat Martineau
Intel
Matthieu Baerts March 3, 2021, 9:01 a.m. UTC | #2
Hi Paolo, Mat,

On 03/03/2021 02:56, Mat Martineau wrote:
> On Tue, 2 Mar 2021, Paolo Abeni wrote:
> 
>> This address the issue the easy way: removing the bugged feature
>> (mcast support :).
>>
>> AFAICS the mcast related sockopt manipulate a global state, so there
>> could be existing working application doing setsockopt(mcast opt) on
>> TCP sockets. This is why I did not disable mcast at the inet level
>> for stream sockets.
>>
>> Still I'm wondering if we should take the opposite approach: explicitly
>> forbitting all setsockopt except the one we implement in
>> net/mptcp/protocol.c
>>
> 
> I think there was mailing list discussion about having an allowed list 
> of SOL_TCP options, but I think applying that idea to the inet level 
> slipped by. It does seem better to only allow the options we implement.

Yes and probably easier to maintain a list of what has been implemented 
and/or validated (who mentioned packetdrill???) than having to block one 
because it can cause warnings or crashes.

BTW thank you for looking at that!

Cheers,
Matt