netdev - Re: [PATCH net] bridge: Fix incorrect re-injection of LLDP packets

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

Message-Id: <20160725.105416.2123454512115321360.davem@davemloft.net>
Date:	Mon, 25 Jul 2016 10:54:16 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	idosch@...lanox.com
Cc:	stephen@...workplumber.org, netdev@...r.kernel.org,
	bridge@...ts.linux-foundation.org, jiri@...lanox.com,
	eladr@...lanox.com, yotamg@...lanox.com, nogahf@...lanox.com,
	ogerlitz@...lanox.com, fw@...len.de, john.fastabend@...il.com
Subject: Re: [PATCH net] bridge: Fix incorrect re-injection of LLDP packets

From: Ido Schimmel <idosch@...lanox.com>
Date: Fri, 22 Jul 2016 14:56:20 +0300

> Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook
> returns QUEUE or STOLEN verdict") caused LLDP packets arriving through a
> bridge port to be re-injected to the Rx path with skb->dev set to the
> bridge device, but this breaks the lldpad daemon.
> 
> The lldpad daemon opens a packet socket with protocol set to ETH_P_LLDP
> for any valid device on the system, which doesn't not include soft
> devices such as bridge and VLAN.
> 
> Since packet sockets (ptype_base) are processed in the Rx path after the
> Rx handler, LLDP packets with skb->dev set to the bridge device never
> reach the lldpad daemon.
> 
> Fix this by making the bridge's Rx handler re-inject LLDP packets with
> RX_HANDLER_PASS, which effectively restores the behaviour prior to the
> mentioned commit.
> 
> This means netfilter will never receive LLDP packets coming through a
> bridge port, as I don't see a way in which we can have okfn() consume
> the packet without breaking existing behaviour. I've already carried out
> a similar fix for STP packets in commit 56fae404fb2c ("bridge: Fix
> incorrect re-injection of STP packets").
> 
> Fixes: 8626c56c8279 ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict")
> Signed-off-by: Ido Schimmel <idosch@...lanox.com>
> Reviewed-by: Jiri Pirko <jiri@...lanox.com>

Applied, but... sigh... nothing about bridging and netfilter is clean,
what a mess.