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] [day] [month] [year] [list]

Message-Id: <20171211.151605.338267507460459106.davem@davemloft.net>
Date:   Mon, 11 Dec 2017 15:16:05 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     maheshb@...gle.com
Cc:     mahesh@...dewar.net, netdev@...r.kernel.org, edumazet@...gle.com,
        amit.sikka@...csson.com
Subject: Re: [PATCH next] ipvlan: add L2 check for packets arriving via
 virtual devices

From: Mahesh Bandewar (महेश बंडेवार) <maheshb@...gle.com>
Date: Mon, 11 Dec 2017 11:38:04 -0800

> 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 for looking more deeply into this.