netdev - Re: [PATCH next] ipvlan: add L2 check for packets arriving via virtual devices

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAF2d9jit3jNemKVU0tXHNOknpb=pXejXi1Y+1aFGdHfAVcbjwQ@mail.gmail.com>
Date:   Mon, 11 Dec 2017 11:38:04 -0800
From:   Mahesh Bandewar (महेश बंडेवार) 
        <maheshb@...gle.com>
To:     David Miller <davem@...emloft.net>
Cc:     mahesh@...dewar.net, linux-netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>, amit.sikka@...csson.com
Subject: Re: [PATCH next] ipvlan: add L2 check for packets arriving via
 virtual devices

On Mon, Dec 11, 2017 at 8:15 AM, David Miller <davem@...emloft.net> wrote:
> From: Mahesh Bandewar <mahesh@...dewar.net>
> Date: Thu,  7 Dec 2017 15:15:43 -0800
>
>> From: Mahesh Bandewar <maheshb@...gle.com>
>>
>> Packets that don't have dest mac as the mac of the master device should
>> not be entertained by the IPvlan rx-handler. This is mostly true as the
>> packet path mostly takes care of that, except when the master device is
>> a virtual device. As demonstrated in the following case -
>  ...
>> This patch adds that missing check in the IPvlan rx-handler.
>>
>> Reported-by: Amit Sikka <amit.sikka@...csson.com>
>> Signed-off-by: Mahesh Bandewar <maheshb@...gle.com>
>
> Applied, but it's a shame that the data plane takes on this new MAC
> compare operation.
Your comment made me think little more about this and a discussion
with Eric kind of put things in perspective. eth_type_trans() does the
right thing and sets the packet_type correctly (when .ndo_xmit of veth
is called). However IPvlan is over-aggressive in packet scrubbing and
that scrub changes packet type. This causes the actual problem. It's
not clear to me why skb_scrub_packet() changes the packet type to
PACKET_HOST unconditionally? But that's another issue.

I'll send another patch to remove excessive scrubbing in IPvlan and
revert of this patch so that this additional comparison (though not
expensive!) can be avoided.

Thanks,
--mahesh..