netdev - Re: [Bug 196093] New: dot1q S-VLAN frame on dot1ad configured interface is accepted

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: <103FD5F2-1506-4B54-A3A3-A533F39496D7@lixfeld.ca>
Date:   Mon, 19 Jun 2017 11:57:09 -0400
From:   Jason Lixfeld <jason@...feld.ca>
To:     Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org, Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        jason-kernelbugzilla@...feld.ca
Subject: Re: [Bug 196093] New: dot1q S-VLAN frame on dot1ad configured
 interface is accepted

Confirmed.  Works with 1.8.1-3 on Debian via unstable.

> On Jun 18, 2017, at 10:35 PM, Toshiaki Makita <makita.toshiaki@....ntt.co.jp> wrote:
> 
> Hi,
> 
> On 2017/06/17 0:40, Stephen Hemminger wrote:
>> I suspect that VLAN offload on this Intel NIC is allowing any of the VLAN types.
>> 
>> Begin forwarded message:
>> 
>> Date: Fri, 16 Jun 2017 15:33:35 +0000
>> From: bugzilla-daemon@...zilla.kernel.org
>> To: stephen@...workplumber.org
>> Subject: [Bug 196093] New: dot1q S-VLAN frame on dot1ad configured interface is accepted
>> 
>> 
>> https://bugzilla.kernel.org/show_bug.cgi?id=196093
>> 
>>            Bug ID: 196093
>>           Summary: dot1q S-VLAN frame on dot1ad configured interface is
>>                    accepted
>>           Product: Networking
>>           Version: 2.5
>>    Kernel Version: 3.16.0 and 4.9.0
>>          Hardware: Intel
>>                OS: Linux
>>              Tree: Mainline
>>            Status: NEW
>>          Severity: normal
>>          Priority: P1
>>         Component: Other
>>          Assignee: stephen@...workplumber.org
>>          Reporter: jason-kernelbugzilla@...feld.ca
>>        Regression: No
>> 
>> Using the following configuration on an Intel 82599 port.  Tested in Debian 8
>> with Kernel 3.16.0 and 4.9.0:
>> 
>> ip link set dev eth4 up
>> ip link add link eth4 eth4.100ad type vlan proto 802.1ad id 100
>> ip link add link eth4.100ad eth4.100ad.10q type vlan proto 802.1Q id 10
>> ip link set dev eth4 netns nni-ad
>> ip link set dev eth4.100ad netns nni-ad
>> ip link set dev eth4.100ad.10q netns nni-ad
>> ip netns exec nni-ad ip link set dev eth4 up
>> ip netns exec nni-ad ip link set dev eth4.100ad up
>> ip netns exec nni-ad ip link set dev eth4.100ad.10q up
>> ip netns exec nni-ad ip addr add 10.4.100.10/8 dev eth4.100ad.10q
>> 
>> Ping to 10.4.100.10 while doing tcpdump on eth4 shows the frame has ether type
>> 0x8100 (dot1q) on the S-VLAN, not 0x88a8 (dot1ad), yet the frame is still
> 
> libpcap was not reliable in vlan protocol parsing.
> https://github.com/the-tcpdump-group/libpcap/pull/346
> AFAIK libpcap 1.7.2 is required to parse it correctly.
> 
>> accepted, and an echo reply is generated.
>> 
>> The echo reply has the correct ethertype on the S-VLAN (0x88a8).  My
>> understanding is that if the frame received on the wire does not match the
>> ether type of the configured interface, the frame should be dropped?
> 
> Yes, it should.
> 
> Toshiaki Makita
>