netdev - Re: [PATCH net] macvlan: filter out xfrm feature 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]

Date:   Thu, 8 Mar 2018 15:34:02 -0800
From:   Shannon Nelson <shannon.nelson@...cle.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, steffen.klassert@...unet.com
Subject: Re: [PATCH net] macvlan: filter out xfrm feature flags

On 3/8/2018 9:33 AM, David Miller wrote:
> From: Shannon Nelson <shannon.nelson@...cle.com>
> Date: Tue,  6 Mar 2018 14:57:08 -0800
> 
>> This isn't broken for vlans because they use a separate features
>> connection (vlan_features) for inheriting features.  This is
>> fine, but I don't think trying to add something like this to
>> every driver for every new upperdev is a good idea - I think
>> the upperdev should try to protect itself.
> 
> I think this fix is correct.
> 
> But for how many upperdevs are we going to duplicate code like this,
> and how many subtle differences and in fact bugs will result from all
> of that duplication?
> 
> I think we really need something common for these upperdev drivers
> to use.  Maybe just a macro defining feature bits to trim in this
> situation.
> 
> Thanks.

Thanks, Dave.  Yes, this could use something a little more generic, 
something that would catch any future "dangerous" bits.

I'm not sure we can come up with a generic mask to be used by everyone, 
as each upper and lower dev has their own feature support levels.  But 
we might come up with a better example for others to follow.

Rather than calling out specific non-supported bits, we can probably 
just build a mask from bits that we already know are supported, 
something like this:
	features &= (ALWAYS_ON_FEATURES | MACVLAN_FEATURES);

which would take care of NETIF_F_NETNS_LOCAL, the ESP flags, and 
anything else that wasn't already specifically called for.  I'll repost 
with this and see what folks think.

sln