From: Guillaume Nault <gnault@redhat.com>
To: Eric Dumazet <edumazet@google.com>
Cc: "David S . Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
James Chapman <jchapman@katalix.com>
Subject: Re: [PATCH net] l2tp: use rcu_dereference_sk_user_data() in l2tp_udp_encap_recv()
Date: Wed, 24 Apr 2019 21:04:13 +0200 [thread overview]
Message-ID: <20190424190413.GC17274@pc-2.home> (raw)
In-Reply-To: <CANn89iJbvXW+Zrap-PczUd-0M8iRzcOL0riMxF8YoXyMBtVK+Q@mail.gmail.com>
On Wed, Apr 24, 2019 at 11:29:25AM -0700, Eric Dumazet wrote:
> On Wed, Apr 24, 2019 at 11:21 AM Guillaume Nault <gnault@redhat.com> wrote:
>
> >
> > And then, we'd need to make sure that ->sk_user_data is in sync with
> > the encap_rcv() callback (or whatever actually uses the data pointed
> > to). Otherwise a module could treat ->sk_user_data as a struct foo
> > pointer while it actually points to a struct bar.
> >
> > For example, a quick look at net/sunrpc/svcsock.c seems to indicate
> > that svc_addsock() would accept any (unconnected) UDP socket and pass
> > it to svc_addsock(), which in turn would override ->sk_user_data with
> > a struct svc_sock pointer. If the socket was previously set up by L2TP,
> > then we'd end up with ->sk_user_data pointing to a svc_sock structure,
> > but ->encap_rcv still pointing to l2tp_udp_encap_recv(). That's going
> > to give unexpected results when l2tp_udp_encap_recv() will dereference
> > ->sk_user_data to access (what it believes to be) its tunnel structure.
>
> A full audit is needed, and I have started it. If you want to help
> just send a patch ;)
>
> I have looked at this l2tp code only after fixing another issue in
> RXRPC, and would have
> looked later at SUNRPC.
Hum, sorry, I didn't realise that. I'm really interested in the
solutions you can come up with.
prev parent reply other threads:[~2019-04-24 19:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 16:43 [PATCH net] l2tp: use rcu_dereference_sk_user_data() in l2tp_udp_encap_recv() Eric Dumazet
2019-04-24 9:58 ` Guillaume Nault
2019-04-24 11:33 ` Eric Dumazet
2019-04-24 18:21 ` Guillaume Nault
2019-04-24 18:29 ` Eric Dumazet
2019-04-24 19:04 ` Guillaume Nault [this message]
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=20190424190413.GC17274@pc-2.home \
--to=gnault@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=jchapman@katalix.com \
--cc=netdev@vger.kernel.org \
/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.