netdev - Re: Sending 802.1Q packets using AF_PACKET socket on filtered bridge forwards with wrong MAC addresses

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:   Tue, 28 Nov 2017 15:37:40 -0800
From:   Brandon Carpenter <brandon.carpenter@...herpath.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        bridge@...ts.linux-foundation.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Sending 802.1Q packets using AF_PACKET socket on filtered bridge
 forwards with wrong MAC addresses

I tracked down the function responsible for changing the MAC header.
It is skb_vlan_untag() called from __allowed_ingress() in
net/bridge/br_vlan.c. Before skb_vlan_untag() is called, the MAC
headers are perfect and afterward they are altered as previously
described. I'll continue digging into that function, but if any of you
have insight into what skb_vlan_untag() does and why it might alter
the MAC header the way it does in this special case, I would
appreciate the help.

Thanks,

Brandon

-- 

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
for the sole use of the intended recipient(s) and may contain proprietary, 
confidential or privileged information or otherwise be protected by law. 
Any unauthorized review, use, disclosure or distribution is prohibited. If 
you are not the intended recipient, please notify the sender and destroy 
all copies and the original message.