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

Date:   Fri, 16 Jun 2017 08:40:01 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org, Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Cc:     netdev@...r.kernel.org
Subject: Fw: [Bug 196093] New: dot1q S-VLAN frame on dot1ad configured
 interface is accepted

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
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?

17:44:05.608944 00:0c:bd:08:80:99 > 00:0c:bd:08:80:9a, ethertype 802.1Q
(0x8100), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.3.1.10 > 10.4.100.10: ICMP echo request, id 8919, seq 1, length 64
17:44:05.608983 00:0c:bd:08:80:9a > 00:0c:bd:08:80:99, ethertype 802.1Q-QinQ
(0x88a8), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.4.100.10 > 10.3.1.10: ICMP echo reply, id 8919, seq 1, length 64
17:44:06.608085 00:0c:bd:08:80:99 > 00:0c:bd:08:80:9a, ethertype 802.1Q
(0x8100), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.3.1.10 > 10.4.100.10: ICMP echo request, id 8919, seq 2, length 64
17:44:06.608119 00:0c:bd:08:80:9a > 00:0c:bd:08:80:99, ethertype 802.1Q-QinQ
(0x88a8), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.4.100.10 > 10.3.1.10: ICMP echo reply, id 8919, seq 2, length 64
17:44:07.608080 00:0c:bd:08:80:99 > 00:0c:bd:08:80:9a, ethertype 802.1Q
(0x8100), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.3.1.10 > 10.4.100.10: ICMP echo request, id 8919, seq 3, length 64
17:44:07.608102 00:0c:bd:08:80:9a > 00:0c:bd:08:80:99, ethertype 802.1Q-QinQ
(0x88a8), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.4.100.10 > 10.3.1.10: ICMP echo reply, id 8919, seq 3, length 64
17:44:08.608078 00:0c:bd:08:80:99 > 00:0c:bd:08:80:9a, ethertype 802.1Q
(0x8100), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.3.1.10 > 10.4.100.10: ICMP echo request, id 8919, seq 4, length 64
17:44:08.608109 00:0c:bd:08:80:9a > 00:0c:bd:08:80:99, ethertype 802.1Q-QinQ
(0x88a8), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.4.100.10 > 10.3.1.10: ICMP echo reply, id 8919, seq 4, length 64
17:44:09.608090 00:0c:bd:08:80:99 > 00:0c:bd:08:80:9a, ethertype 802.1Q
(0x8100), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.3.1.10 > 10.4.100.10: ICMP echo request, id 8919, seq 5, length 64
17:44:09.608121 00:0c:bd:08:80:9a > 00:0c:bd:08:80:99, ethertype 802.1Q-QinQ
(0x88a8), length 106: vlan 100, p 0, ethertype 802.1Q, vlan 10, p 0, ethertype
IPv4, 10.4.100.10 > 10.3.1.10: ICMP echo reply, id 8919, seq 5, length 64

-- 
You are receiving this mail because:
You are the assignee for the bug.