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

Message-ID: <20210403095418.GC1463@shell.armlinux.org.uk>
Date:   Sat, 3 Apr 2021 10:54:18 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     netdev@...r.kernel.org
Subject: Semantics of AF_PACKET sockets on bridge port interface

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?

Thanks.

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