All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cong Wang <xiyou.wangcong@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
	syzbot+0bf0519d6e0de15914fe@syzkaller.appspotmail.com,
	Steffen Klassert <steffen.klassert@secunet.com>
Subject: Re: [Patch net] xfrm: unify xfrm protocol checks
Date: Thu, 21 Mar 2019 21:06:05 -0700	[thread overview]
Message-ID: <CAM_iQpU=3nw6WsJ7pb+P3H2sObhbgjcPHRqJcArOPNMPx+n65A@mail.gmail.com> (raw)
In-Reply-To: <20190320053532.o7hawr2vkj6fxbv7@gondor.apana.org.au>

On Tue, Mar 19, 2019 at 10:35 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Mar 19, 2019 at 01:42:53PM -0700, Cong Wang wrote:
> >
> > IIRC, it is Steffen who suggested to add IPPROTO_ROUTING/IPPROTO_DSTOPTS
> > back to commit 6a53b7593233. My xfrm knowledge is not enough to
> > figure out IPPROTO_ROUTING/IPPROTO_DSTOPTS.
>
> OK I dug into the history of xfrm_id_proto_match and this is
> definitely not right.  The intention appears to be that
> IPSEC_PROTO_ANY should only match genuine IPsec protocols, i.e.,
> AH/ESP/COMP, while the special value of zero will match everything.
>
> So I think what we should do is get rid of the validation function
> that you added in 6a5t3b7593233, and then change those internal
> functions which were incorrectly using IPSEC_PROTO_ANY to using
> zero instead.

Good point. Replacing IPSEC_PROTO_ANY with zero should
work too, but on the other hand, id.proto is still never allowed to
be any other protocol than these 6 listed, no?


>
> Does anybody still use IPPROTO_ROUTING/IPPROTO_DSTOPTS? It's always
> a pain when people come and add features and then don't shoulder
> the burden of maintaining them.

Yeah, at least iproute2 does the same check:

static const struct typeent xfrmproto_types[] = {
        { "esp", IPPROTO_ESP }, { "ah", IPPROTO_AH }, { "comp", IPPROTO_COMP },
        { "route2", IPPROTO_ROUTING }, { "hao", IPPROTO_DSTOPTS },
        { "ipsec-any", IPSEC_PROTO_ANY },
        { NULL, -1 }
};

  reply	other threads:[~2019-03-22  4:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19  5:08 [Patch net] xfrm: unify xfrm protocol checks Cong Wang
2019-03-19  5:17 ` Herbert Xu
2019-03-19 20:42   ` Cong Wang
2019-03-20  5:35     ` Herbert Xu
2019-03-22  4:06       ` Cong Wang [this message]
2019-03-22  4:11         ` Herbert Xu
2019-03-22  4:15           ` Cong Wang

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='CAM_iQpU=3nw6WsJ7pb+P3H2sObhbgjcPHRqJcArOPNMPx+n65A@mail.gmail.com' \
    --to=xiyou.wangcong@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=syzbot+0bf0519d6e0de15914fe@syzkaller.appspotmail.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.