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

Date:   Mon, 19 Jun 2017 11:35:26 +0900
From:   Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
To:     Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org, Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        jason-kernelbugzilla@...feld.ca
Subject: Re: Fw: [Bug 196093] New: dot1q S-VLAN frame on dot1ad configured
 interface is accepted

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