netdev - Re: [PATCH net-next 2/2] net/sched: cls_flower: add support for matching tunnel control flags

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAM0EoMkx7RLwRf-m8NRKOLDsuLJ8CUB4kwXojZrHTdY-vpLQ_w@mail.gmail.com>
Date: Thu, 1 Feb 2024 09:59:19 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Davide Caratti <dcaratti@...hat.com>
Cc: Cong Wang <xiyou.wangcong@...il.com>, Jiri Pirko <jiri@...nulli.us>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, 
	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>, Xin Long <lucien.xin@...il.com>, 
	Ilya Maximets <i.maximets@....org>
Subject: Re: [PATCH net-next 2/2] net/sched: cls_flower: add support for
 matching tunnel control flags

Hi Davide,

On Thu, Feb 1, 2024 at 6:14 AM Davide Caratti <dcaratti@...hat.com> wrote:
>
> hello Jamal, thanks for looking at this!
>
> On Wed, Jan 31, 2024 at 04:13:25PM -0500, Jamal Hadi Salim wrote:
> > On Wed, Jan 31, 2024 at 11:16 AM Davide Caratti <dcaratti@...hat.com> wrote:
> > >
> > > extend cls_flower to match flags belonging to 'TUNNEL_FLAGS_PRESENT' mask
> > > inside skb tunnel metadata.
> > >
> > > Suggested-by: Ilya Maximets <i.maximets@....org>
> > > Signed-off-by: Davide Caratti <dcaratti@...hat.com>
>
> [...]
>
> > > @@ -1748,6 +1753,21 @@ static int fl_set_key_cfm(struct nlattr **tb,
> > >         return 0;
> > >  }
> > >
> > > +static int fl_set_key_enc_flags(struct nlattr **tb, __be16 *flags_key,
> > > +                               __be16 *flags_mask, struct netlink_ext_ack *extack)
> > > +{
> > > +       /* mask is mandatory for flags */
> > > +       if (!tb[TCA_FLOWER_KEY_ENC_FLAGS_MASK]) {
> >
> > if (NL_REQ_ATTR_CHECK(extack,...))
> >
> > > +               NL_SET_ERR_MSG(extack, "missing enc_flags mask");
> > > +               return -EINVAL;
> > > +       }
>
> right, I will change it in the v2.
>
> [...]
>
> > > @@ -1986,6 +2006,10 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
> > >                 ret = fl_set_key_flags(tb, &key->control.flags,
> > >                                        &mask->control.flags, extack);
> > >
> > > +       if (tb[TCA_FLOWER_KEY_ENC_FLAGS])
> >
> > And here..
> >
> > cheers,
> > jamal
> >
> > > +               ret = fl_set_key_enc_flags(tb, &key->enc_flags.flags,
> > > +                                          &mask->enc_flags.flags, extack);
> > > +
> > >         return ret;
>
> here I don't see any advantage in doing
>
> if (!NL_REQ_ATTR_CHECK(extack, NULL, tb, TCA_FLOWER_KEY_ENC_FLAGS))
>         ret = fl_set_key_enc_flags(tb, ... );
>
> return ret;
>

Ok, i was a little overzealous there. When i see tb[] my brain goes
NL_REQ_ATTR_CHECK ;->

> the attribute is not mandatory, so a call to NL_SET_ERR_ATTR_MISS()
> would do a useless/misleading assignment in extack->miss_type.
>

True.

> However, thanks for bringing the attention here :) At a second look,
> this hunk introduces a bug: in case the parsing of TCA_FLOWER_KEY_FLAGS
> fails, 'ret' is -EINVAL. If attributes TCA_FLOWER_KEY_ENC_FLAGS +
> TCA_FLOWER_KEY_ENC_FLAGS_MASK are good to go, 'ret' will be overwritten
> with 0 and flower will accept the rule... this is not intentional :)
> will fix this in the v2.
>

np ;->

cheers,
jamal

> --
> davide
>
>