netdev - Re: Semantics of AF_PACKET sockets on bridge port interface

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: <20210403101229.GF1477@shell.armlinux.org.uk>
Date:   Sat, 3 Apr 2021 11:12:29 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     netdev@...r.kernel.org
Subject: Re: Semantics of AF_PACKET sockets on bridge port interface

On Sat, Apr 03, 2021 at 10:54:18AM +0100, Russell King - ARM Linux admin wrote:
> Hi,
> 
> This question has probably come up several times before, but there
> doesn't seem to be a solution yet.
> 
> Scenario: a network interface, such as a wireless adapter or a
> network interface supporting PTP, is part of a bridge. Userspace
> wishes to capture packets sent using a specific Ethernet protocol
> to the ethernet address of that network interface, such as EAPOL
> frames or PTP frames.
> 
> Problem 1: __netif_receive_skb_core() scans the global ptype_all and
> skb->dev->ptype_all lists to deliver to any packet capture sockets,
> then checks skb->dev->rx_handler (which bridge sets), and from which
> it returns RX_HANDLER_CONSUMED from. This bypasses AF_PACKET listeners
> attached via the ->ptype_specific list, resulting in such a socket
> not receiving any packets.
> 
> Problem 2: detecting the port being a bridge port, and having the
> application also bind to the bridge interface is not a solution; the
> bridge can have a different MAC address to the bridge interface, so
> e.g. EAPOL frames sent to the WiFi MAC address will not be routed to
> the bridge interface. (hostapd does this but it's fragile for this
> reason, and it doesn't work for ptp nor does it work for Network
> Manager based bridged Wi-Fi which uses wpa_supplicant.)
> 
> So, this problem really does need solving, but it doesn't look to be
> trivial.  Moving the scanning of the device's ptype_specific list
> has implications for ingress and vlan handling.
> 
> I'm aware of a large patch set in 2019 that contained a single patch
> that claimed to fix it, but it looks like it was ignored, which is
> not surprising given the size and content of the series.
> https://lore.kernel.org/patchwork/patch/1066146/
> This patch no longer applies to current kernels since the bridge code
> has changed, and in any case, I suspect the fix is wrong.
> 
> Is there a solution for this, or are AF_PACKET ethernet-protocol
> specific sockets just not supportable on bridge ports?

Would having the bridge code return RX_HANDLER_EXACT rather than
RX_HANDLER_CONSUMED would solve this problem with minimal side effects?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!