From: Guillaume Nault <g.nault@alphalink.fr>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: James Chapman <jchapman@katalix.com>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, Hangbin Liu <liuhangbin@gmail.com>
Subject: Re: [PATCH net-next 2/2] l2tp: add peer_offset parameter
Date: Wed, 3 Jan 2018 17:35:25 +0100 [thread overview]
Message-ID: <20180103163525.GF1402@alphalink.fr> (raw)
In-Reply-To: <CAJ0CqmWkeb3sKGWy+xgiwCxP=MHA9Zs7cq9-F+6tTAON47R4Jg@mail.gmail.com>
On Wed, Jan 03, 2018 at 04:06:28PM +0100, Lorenzo Bianconi wrote:
> I agree to remove offset parameter in this case. What about (as
> already suggested by James) to take into account possible alignment
> issues with previous version of L2TPv3 protocol using 'L2 specific
> sublayer'?
>
I think James was refering to the general architecture of L2TPv3, where
such issues should be handled by pseudo-wire specific headers. I don't
think he was talking about implementing arbitrary padding using an
L2 specific sublayer. None of the standardised headers allow arbitrary
padding. And implementing our own would make us imcompatible with any
other implementation.
> I guess, on the kernel side (we will need to patch iproute2 on
> userspace side), we need just to properly initialized the 'l2specific'
> field to 0 since otherwise we will have the same memleak issue there
> if assume we can have l2specific_len != {0,4}.
>
That would produce the same frame format as what the 'offset' option
was supposed to produce (if it did properly initialise its padding
bits). That is, we'd have an arbitrary number of padding bits inserted
between the l2-specific header and the l2 frame (L2TP's payload). These
frames are invalid, and doing that brings us nothing compared to
keeping the offset option.
> Moreover does it worth to add some sanity checks in netlink code to
> enforce the relation between l2specific_len and l2specific_type?
>
Yes, certainly.
> At
> the moment there are no guarantee that if l2specific_type is set to
> L2TP_L2SPECTYPE_DEFAULT, l2specific_len will be grater or equal than
> 4.
>
Thanks for pointing this out. That needs to be fixed. We don't support
anything but the default l2spec layer (or no l2spec layer at all). So
we should only accept L2TP_L2SPECTYPE_NONE and L2TP_L2SPECTYPE_DEFAULT.
And we shouldn't need to use l2specific_len at all. The default l2spec
header is always four bytes long, so we don't need to rely on a user
supplied value. Looking at the code, it seems that invalid usage of
L2TP_ATTR_L2SPEC_LEN allows leaking memory on the network or sending
corrupted frames (depending on if its value is too small or too big).
Do you want to take care of this?
next prev parent reply other threads:[~2018-01-03 16:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-22 14:10 [PATCH net-next 0/2] l2tp: fix offset/peer_offset conf parameters Lorenzo Bianconi
2017-12-22 14:10 ` [PATCH net-next 1/2] l2tp: fix missing print session offset info Lorenzo Bianconi
2017-12-22 14:10 ` [PATCH net-next 2/2] l2tp: add peer_offset parameter Lorenzo Bianconi
2017-12-28 14:53 ` Guillaume Nault
2017-12-28 18:23 ` Lorenzo Bianconi
2017-12-28 19:45 ` Guillaume Nault
2017-12-29 18:53 ` James Chapman
2017-12-29 22:21 ` Lorenzo Bianconi
2018-01-02 18:05 ` Guillaume Nault
2018-01-02 19:28 ` Lorenzo Bianconi
2018-01-02 20:18 ` James Chapman
2018-01-03 14:16 ` Guillaume Nault
2018-01-03 15:06 ` Lorenzo Bianconi
2018-01-03 16:35 ` Guillaume Nault [this message]
2018-01-08 17:27 ` Lorenzo Bianconi
2018-01-02 20:08 ` James Chapman
2018-01-02 20:59 ` James Chapman
2018-01-03 14:27 ` Guillaume Nault
2018-01-02 17:50 ` Guillaume Nault
2018-01-02 20:08 ` James Chapman
2017-12-27 17:12 ` [PATCH net-next 0/2] l2tp: fix offset/peer_offset conf parameters David Miller
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=20180103163525.GF1402@alphalink.fr \
--to=g.nault@alphalink.fr \
--cc=davem@davemloft.net \
--cc=jchapman@katalix.com \
--cc=liuhangbin@gmail.com \
--cc=lorenzo.bianconi@redhat.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 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).