netdev - Re: [PATCH] macvlan: verify MTU before lowerdev xmit

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

Message-ID: <5745f546-25d1-2778-1894-159fc026cadf@oracle.com>
Date:   Tue, 14 Nov 2017 11:06:09 -0800
From:   Shannon Nelson <shannon.nelson@...cle.com>
To:     Daniel Axtens <dja@...ens.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] macvlan: verify MTU before lowerdev xmit

On 11/14/2017 9:03 AM, Shannon Nelson wrote:
> On 11/14/2017 2:32 AM, Daniel Axtens wrote:
>> If a macvlan device which is not in bridge mode receives a packet,
>> it is sent straight to the lowerdev without checking against the
>> device's MTU. This also happens for multicast traffic.
>>
>> Add an is_skb_forwardable() check against the lowerdev before
>> sending the packet out through it. I think this is the simplest
>> and best way to do it, and is consistent with the use of
>> dev_forward_skb() in the bridge path.
>>
>> This is easy to replicate:
>>   - create a VM with a macvtap connection in private mode
>>   - set the lowerdev MTU to something low in the host (e.g. 1480)
>>   - do not set the MTU lower in the guest (e.g. keep at 1500)
>>   - netperf to a different host with the same high MTU
>>   - observe that currently, the driver will forward too-big packets
>>   - observe that with this patch the packets are dropped
>>
>> Cc: Shannon Nelson <shannon.nelson@...cle.com>
>> Signed-off-by: Daniel Axtens <dja@...ens.net>
>>
>> ---
>>
>> After hearing Shannon's lightning talk on macvlan at netdev I
>> figured I'd strike while the iron is hot and get this out of my
>> patch queue where it has been languishing.
>> ---
>>   drivers/net/macvlan.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>> index a178c5efd33e..8adcad6798c5 100644
>> --- a/drivers/net/macvlan.c
>> +++ b/drivers/net/macvlan.c
>> @@ -534,6 +534,10 @@ static int macvlan_queue_xmit(struct sk_buff 
>> *skb, struct net_device *dev)
>>       }
>>   xmit_world:
>> +    /* verify MTU */
>> +    if (!is_skb_forwardable(vlan->lowerdev, skb))
>> +        return NET_XMIT_DROP;
>> +
> 
> Good catch.  I remember your comment on this last week, but hadn't had a 
> chance to look it up yet.
> 
> As for the other paths, I see that the call to dev_forward_skb() already 
> has this protection in it, but does the call to dev_queue_xmit_accel() 
> in macvlan_start_xmit() need similar protection?
> 

Now that I think about this a little more, why is this not already 
getting handled by the NETDEV_CHANGEMTU notifier?  In what case are you 
running into this, and why is it not triggering the notifier?

sln


> 
> 
>>       skb->dev = vlan->lowerdev;
>>       return dev_queue_xmit(skb);
>>   }
>>