From: Guillaume Nault <g.nault@alphalink.fr>
To: Tom Herbert <tom@herbertland.com>
Cc: netdev@vger.kernel.org, James Chapman <jchapman@katalix.com>
Subject: Re: [PATCH net-next] kcm: do not attach sockets if sk_user_data is already used
Date: Tue, 16 Jan 2018 11:44:25 +0100 [thread overview]
Message-ID: <20180116104425.GA1394@alphalink.fr> (raw)
In-Reply-To: <1515929577-25914-1-git-send-email-jchapman@katalix.com>
On Sun, Jan 14, 2018 at 11:32:57AM +0000, James Chapman wrote:
> SIOCKCMATTACH writes a connected socket's sk_user_data for its own
> use. Prevent it doing so if the socket's sk_user_data is already set
> since some sockets (e.g. encapsulated sockets) use sk_user_data
> internally.
>
> diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
> index d4e98f20fc2a..65392ed58f4a 100644
> --- a/net/kcm/kcmsock.c
> +++ b/net/kcm/kcmsock.c
> @@ -1391,6 +1391,10 @@ static int kcm_attach(struct socket *sock, struct socket *csock,
> if (csk->sk_family == PF_KCM)
> return -EOPNOTSUPP;
>
> + /* Cannot proceed if connected socket already uses sk_user_data */
> + if (csk->sk_user_data)
> + return -EOPNOTSUPP;
> +
> psock = kmem_cache_zalloc(kcm_psockp, GFP_KERNEL);
> if (!psock)
> return -ENOMEM;
>
Isn't that racy? What if sk_user_data was concurrently set right after
this test?
Also, it looks like we could create a UDP socket, attach it to KCM,
then create an L2TP tunnel on this same UDP socket. l2tp_tunnel_create()
or setup_udp_tunnel_sock() would unconditionally overwrite
sk_user_data, which will probably confuse KCM.
Tom, if I understand KCM correctly, it only makes sense to attach it to
SOCK_STREAM sockets. Shouldn't that be enforced? Maybe we should
restrict it even further, so that only known KCM-safe sockets could be
attached (that is, reject anything that isn't AF_INET* | SOCK_STREAM).
next prev parent reply other threads:[~2018-01-16 10:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-14 11:32 [PATCH net-next] kcm: do not attach sockets if sk_user_data is already used James Chapman
2018-01-16 10:44 ` Guillaume Nault [this message]
2018-01-16 17:10 ` Eric Dumazet
2018-01-16 17:36 ` Tom Herbert
2018-01-16 19:00 ` David Miller
2018-01-17 11:13 ` James Chapman
2018-01-17 19:25 ` David Miller
2018-01-18 15:18 ` Guillaume Nault
2018-01-18 15:40 ` James Chapman
2018-01-18 16:29 ` Guillaume Nault
2018-01-18 17:30 ` James Chapman
2018-01-18 17:46 ` Tom Herbert
2018-01-18 18:08 ` Eric Dumazet
2018-01-18 19:26 ` Tom Herbert
2018-01-18 19:46 ` Eric Dumazet
2018-01-18 17:40 ` Tom Herbert
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=20180116104425.GA1394@alphalink.fr \
--to=g.nault@alphalink.fr \
--cc=jchapman@katalix.com \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).