linux-stable.git/net/bridge, branch linux-4.6.y

bridge: Fix incorrect re-injection of LLDP packets

2016-08-16T07:33:16+00:00

[ Upstream commit baedbe55884c003819f5c8c063ec3d2569414296 ]

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 
Reviewed-by: Jiri Pirko 
Cc: Florian Westphal 
Cc: John Fastabend 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address

2016-07-11T16:30:00+00:00

[ Upstream commit 0888d5f3c0f183ea6177355752ada433d370ac89 ]

The bridge is falsly dropping ipv6 mulitcast packets if there is:
 1. No ipv6 address assigned on the brigde.
 2. No external mld querier present.
 3. The internal querier enabled.

When the bridge fails to build mld queries, because it has no
ipv6 address, it slilently returns, but keeps the local querier enabled.
This specific case causes confusing packet loss.

Ipv6 multicast snooping can only work if:
 a) An external querier is present
 OR
 b) The bridge has an ipv6 address an is capable of sending own queries

Otherwise it has to forward/flood the ipv6 multicast traffic,
because snooping cannot work.

This patch fixes the issue by adding a flag to the bridge struct that
indicates that there is currently no ipv6 address assinged to the bridge
and returns a false state for the local querier in
__br_multicast_querier_exists().

Special thanks to Linus Lüssing.

Fixes: d1d81d4c3dd8 ("bridge: check return value of ipv6_dev_get_saddr()")
Signed-off-by: Daniel Danzberger 
Acked-by: Linus Lüssing 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: Don't insert unnecessary local fdb entry on changing mac address

2016-06-24T17:22:01+00:00

[ Upstream commit 0b148def403153a4d1565f1640356cb78ce5109f ]

The missing br_vlan_should_use() test caused creation of an unneeded
local fdb entry on changing mac address of a bridge device when there is
a vlan which is configured on a bridge port but not on the bridge
device.

Fixes: 2594e9064a57 ("bridge: vlan: add per-vlan struct and move to rhashtables")
Signed-off-by: Toshiaki Makita 
Acked-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: fix igmp / mld query parsing

2016-05-06T16:55:13+00:00

With the newly introduced helper functions the skb pulling is hidden
in the checksumming function - and undone before returning to the
caller.

The IGMP and MLD query parsing functions in the bridge still
assumed that the skb is pointing to the beginning of the IGMP/MLD
message while it is now kept at the beginning of the IPv4/6 header.

If there is a querier somewhere else, then this either causes
the multicast snooping to stay disabled even though it could be
enabled. Or, if we have the querier enabled too, then this can
create unnecessary IGMP / MLD query messages on the link.

Fixing this by taking the offset between IP and IGMP/MLD header into
account, too.

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich 
Signed-off-by: Linus Lüssing 
Signed-off-by: David S. Miller

net: bridge: fix old ioctl unlocked net device walk

2016-05-06T03:32:30+00:00

get_bridge_ifindices() is used from the old "deviceless" bridge ioctl
calls which aren't called with rtnl held. The comment above says that it is
called with rtnl but that is not really the case.
Here's a sample output from a test ASSERT_RTNL() which I put in
get_bridge_ifindices and executed "brctl show":
[  957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30)
[  957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G        W  O
4.6.0-rc4+ #157
[  957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[  957.423009]  0000000000000000 ffff880058adfdf0 ffffffff8138dec5
0000000000000400
[  957.423009]  ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32
0000000000000001
[  957.423009]  00007ffec1a444b0 0000000000000400 ffff880053c19130
0000000000008940
[  957.423009] Call Trace:
[  957.423009]  [] dump_stack+0x85/0xc0
[  957.423009]  []
br_ioctl_deviceless_stub+0x212/0x2e0 [bridge]
[  957.423009]  [] sock_ioctl+0x22b/0x290
[  957.423009]  [] do_vfs_ioctl+0x95/0x700
[  957.423009]  [] SyS_ioctl+0x79/0x90
[  957.423009]  [] entry_SYSCALL_64_fastpath+0x23/0xc1

Since it only reads bridge ifindices, we can use rcu to safely walk the net
device list. Also remove the wrong rtnl comment above.

Signed-off-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller

bridge: mdb: Marking port-group as offloaded

2016-04-24T18:23:32+00:00

There is a race-condition when updating the mdb offload flag without using
the mulicast_lock. This reverts commit 9e8430f8d60d98 ("bridge: mdb:
Passing the port-group pointer to br_mdb module").

This patch marks offloaded MDB entry as "offload" by changing the port-
group flags and marks it as MDB_PG_FLAGS_OFFLOAD.

When switchdev PORT_MDB succeeded and adds a multicast group, a completion
callback is been invoked "br_mdb_complete". The completion function
locks the multicast_lock and finds the right net_bridge_port_group and
marks it as offloaded.

Fixes: 9e8430f8d60d98 ("bridge: mdb: Passing the port-group pointer to br_mdb module")
Reported-by: Nikolay Aleksandrov 
Signed-off-by: Elad Raz 
Signed-off-by: Jiri Pirko 
Reviewed-by: Ido Schimmel 
Acked-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller

bridge: mdb: Common function for mdb entry translation

2016-04-24T18:23:32+00:00

There is duplicate code that translates br_mdb_entry to br_ip let's wrap it
in a common function.

Signed-off-by: Elad Raz 
Signed-off-by: Jiri Pirko 
Reviewed-by: Ido Schimmel 
Acked-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller

netfilter: ebtables: Fix extension lookup with identical name

2016-04-12T23:16:57+00:00

If a requested extension exists as module and is not loaded,
ebt_check_match() might accidentally use an NFPROTO_UNSPEC one with same
name and fail.

Reproduced with limit match: Given xt_limit and ebt_limit both built as
module, the following would fail:

  modprobe xt_limit
  ebtables -I INPUT --limit 1/s -j ACCEPT

The fix is to make ebt_check_match() distrust a found NFPROTO_UNSPEC
extension and retry after requesting an appropriate module.

Cc: Florian Westphal 
Signed-off-by: Phil Sutter 
Acked-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

Revert "bridge: Fix incorrect variable assignment on error path in br_sysfs_addbr"

2016-04-06T19:42:45+00:00

This reverts commit c862cc9b70526a71d07e7bd86d9b61d1c792cead.

Patch lacks a real-name Signed-off-by.

Signed-off-by: David S. Miller

bridge: Fix incorrect variable assignment on error path in br_sysfs_addbr

2016-04-04T20:12:37+00:00

This fixes the incorrect variable assignment on error path in
br_sysfs_addbr for when the call to kobject_create_and_add
fails to assign the value of -EINVAL to the returned variable of
err rather then incorrectly return zero making callers think this
function has succeededed due to the previous assignment being
assigned zero when assigning it the successful return value of
the call to sysfs_create_group which is zero.

Signed-off-by: Bastien Philbert 
Signed-off-by: David S. Miller