From: Florian Westphal <fw at strlen.de>
To: mptcp at lists.01.org
Subject: [MPTCP] Re: [syzkaller] KASAN: use-after-free Write in __lock_sock
Date: Tue, 04 Feb 2020 11:46:17 +0100 [thread overview]
Message-ID: <20200204104617.GF15904@breakpoint.cc> (raw)
In-Reply-To: 5b235b4f2636c7621be6a8526e8b6f5cfb7852de.camel@redhat.com
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
Paolo Abeni <pabeni(a)redhat.com> wrote:
> On Tue, 2020-02-04 at 00:59 +0100, Florian Westphal wrote:
> > AFAICS we need to revert to a state we had very early on:
> > proxy tcp fallback case everywhere: msk is left alone and
> > sendmsg/recvmsg and so on invoke the tcp versions on the (only) ssk.
>
> That is unfortunated, I liked the fact that a fallback socket got the
> same performances of a plain TCP socket (could encourage MPTCP adoption
> - not sure that is good thing, anyway ;)
Heh.
> On the plus side, __mptcp_tcp_fallback() should be already hooked in
> every place where we need special/single subflow handling. Should be
> just a matter of simplify __mptcp_tcp_fallback() to just return the
> subflow sk.
Yes, I can confirm that I don't get a crash when i dumb-down the
fallback to always proxy.
> I guess/hope we can still call mptcp_subflow_tcp_fallback() - so that
> at least we get no overhead in the BH processing for the fall-back sk.
Right, I will have a look to see if we can repair it somehow.
If we have to go with always-proxy we will still have the server-side
mostly covered hwoever, mptcp accept will still return plain tcp sk for
non-mptcp syn case.
next reply other threads:[~2020-02-04 10:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 10:46 Florian Westphal [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-02-04 12:34 [MPTCP] Re: [syzkaller] KASAN: use-after-free Write in __lock_sock Matthieu Baerts
2020-02-04 9:12 Paolo Abeni
2020-02-04 6:55 Florian Westphal
2020-02-04 0:24 Christoph Paasch
2020-02-03 23:59 Florian Westphal
2020-02-03 20:52 Christoph Paasch
2020-02-03 10:49 Paolo Abeni
2020-02-01 1:12 Christoph Paasch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200204104617.GF15904@breakpoint.cc \
--to=unknown@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.