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(-)

-- 
2.26.2