linux-stable.git/net/bridge, branch v5.18.2

net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-19T07:20:44+00:00

It is possible to stack bridges on top of each other. Consider the
following which makes use of an Ethernet switch:

       br1
     /    \
    /      \
   /        \
 br0.11    wlan0
   |
   br0
 /  |  \
p1  p2  p3

br0 is offloaded to the switch. Above br0 is a vlan interface, for
vlan 11. This vlan interface is then a slave of br1. br1 also has a
wireless interface as a slave. This setup trunks wireless lan traffic
over the copper network inside a VLAN.

A frame received on p1 which is passed up to the bridge has the
skb->offload_fwd_mark flag set to true, indicating that the switch has
dealt with forwarding the frame out ports p2 and p3 as needed. This
flag instructs the software bridge it does not need to pass the frame
back down again. However, the flag is not getting reset when the frame
is passed upwards. As a result br1 sees the flag, wrongly interprets
it, and fails to forward the frame to wlan0.

When passing a frame upwards, clear the flag. This is the Rx
equivalent of br_switchdev_frame_unmark() in br_dev_xmit().

Fixes: f1c2eddf4cb6 ("bridge: switchdev: Use an helper to clear forward mark")
Signed-off-by: Andrew Lunn 
Reviewed-by: Ido Schimmel 
Tested-by: Ido Schimmel 
Acked-by: Nikolay Aleksandrov 
Link: https://lore.kernel.org/r/20220518005840.771575-1-andrew@lunn.ch
Signed-off-by: Paolo Abeni

net: bridge: switchdev: check br_vlan_group() return value

2022-04-22T22:12:18+00:00

br_vlan_group() can return NULL and thus return value must be checked
to avoid dereferencing a NULL pointer.

Fixes: 6284c723d9b9 ("net: bridge: mst: Notify switchdev drivers of VLAN MSTI migrations")
Signed-off-by: Clément Léger 
Acked-by: Nikolay Aleksandrov 
Link: https://lore.kernel.org/r/20220421101247.121896-1-clement.leger@bootlin.com
Signed-off-by: Jakub Kicinski

net: bridge: mst: Restrict info size queries to bridge ports

2022-03-23T17:32:44+00:00

Ensure that no bridge masters are ever considered for MST info
dumping. MST states are only supported on bridge ports, not bridge
masters - which br_mst_info_size relies on.

Fixes: 122c29486e1f ("net: bridge: mst: Support setting and reporting MST port states")
Signed-off-by: Tobias Waldekranz 
Link: https://lore.kernel.org/r/20220322133001.16181-1-tobias@waldekranz.com
Signed-off-by: Jakub Kicinski

net: bridge: mst: prevent NULL deref in br_mst_info_size()

2022-03-22T11:47:51+00:00

Call br_mst_info_size() only if vg pointer is not NULL.

general protection fault, probably for non-canonical address 0xdffffc0000000058: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000002c0-0x00000000000002c7]
CPU: 0 PID: 975 Comm: syz-executor.0 Tainted: G        W         5.17.0-next-20220321-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:br_mst_info_size+0x97/0x270 net/bridge/br_mst.c:242
Code: 00 00 31 c0 e8 ba 10 53 f9 31 c0 b9 40 00 00 00 4c 8d 6c 24 30 4c 89 ef f3 48 ab 48 8d 83 c0 02 00 00 48 89 04 24 48 c1 e8 03 <80> 3c 28 00 0f 85 ae 01 00 00 48 8b 83 c0 02 00 00 41 bf 04 00 00
RSP: 0018:ffffc900153770a8 EFLAGS: 00010202
RAX: 0000000000000058 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff88259876 RDI: ffffc900153772d8
RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffffff8db68957
R10: ffffffff881f737b R11: 0000000000000000 R12: 0000000000000000
R13: ffffc900153770d8 R14: 00000000000002a0 R15: 00000000ffffffff
FS:  00007f18bbb6f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020001a80 CR3: 000000001a7d9000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 00000000000000d8 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 
 br_get_link_af_size_filtered+0x6e9/0xc00 net/bridge/br_netlink.c:123
 rtnl_link_get_af_size net/core/rtnetlink.c:598 [inline]
 if_nlmsg_size+0x40c/0xa50 net/core/rtnetlink.c:1040
 rtnl_calcit.isra.0+0x25f/0x460 net/core/rtnetlink.c:3780
 rtnetlink_rcv_msg+0xa65/0xb80 net/core/rtnetlink.c:5937
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:705 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:725
 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2413
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2467
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2496
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f18baa89049
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f18bbb6f168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f18bab9bf60 RCX: 00007f18baa89049
RDX: 0000000000000000 RSI: 0000000020001a80 RDI: 0000000000000004
RBP: 00007f18baae308d R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffeedb2be2f R14: 00007f18bbb6f300 R15: 0000000000022000
 
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:br_mst_info_size+0x97/0x270 net/bridge/br_mst.c:242
Code: 00 00 31 c0 e8 ba 10 53 f9 31 c0 b9 40 00 00 00 4c 8d 6c 24 30 4c 89 ef f3 48 ab 48 8d 83 c0 02 00 00 48 89 04 24 48 c1 e8 03 <80> 3c 28 00 0f 85 ae 01 00 00 48 8b 83 c0 02 00 00 41 bf 04 00 00
RSP: 0018:ffffc900153770a8 EFLAGS: 00010202
RAX: 0000000000000058 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff88259876 RDI: ffffc900153772d8
RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffffff8db68957
R10: ffffffff881f737b R11: 0000000000000000 R12: 0000000000000000
R13: ffffc900153770d8 R14: 00000000000002a0 R15: 00000000ffffffff
FS:  00007f18bbb6f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2ca22000 CR3: 000000001a7d9000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 00000000000000d8 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Fixes: 122c29486e1f ("net: bridge: mst: Support setting and reporting MST port states")
Reported-by: syzbot 
Signed-off-by: Eric Dumazet 
Cc: Tobias Waldekranz 
Cc: Nikolay Aleksandrov 
Reviewed-by: Tobias Waldekranz 
Acked-by: Nikolay Aleksandrov 
Link: https://lore.kernel.org/r/20220322012314.795187-1-eric.dumazet@gmail.com
Signed-off-by: Paolo Abeni

netfilter: nft_meta: extend reduce support to bridge family

2022-03-19T23:29:46+00:00

its enough to export the meta get reduce helper and then call it
from nft_meta_bridge too.

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

netfilter: nf_tables: cancel tracking for clobbered destination registers

2022-03-19T23:29:46+00:00

Output of expressions might be larger than one single register, this might
clobber existing data. Reset tracking for all destination registers that
required to store the expression output.

This patch adds three new helper functions:

- nft_reg_track_update: cancel previous register tracking and update it.
- nft_reg_track_cancel: cancel any previous register tracking info.
- __nft_reg_track_cancel: cancel only one single register tracking info.

Partial register clobbering detection is also supported by checking the
.num_reg field which describes the number of register that are used.

This patch updates the following expressions:

- meta_bridge
- bitwise
- byteorder
- meta
- payload

to use these helper functions.

Signed-off-by: Pablo Neira Ayuso

netfilter: nf_tables: do not reduce read-only expressions

2022-03-19T23:29:46+00:00

Skip register tracking for expressions that perform read-only operations
on the registers. Define and use a cookie pointer NFT_REDUCE_READONLY to
avoid defining stubs for these expressions.

This patch re-enables register tracking which was disabled in ed5f85d42290
("netfilter: nf_tables: disable register tracking"). Follow up patches
add remaining register tracking for existing expressions.

Signed-off-by: Pablo Neira Ayuso

net: bridge: mst: Add helper to query a port's MST state

2022-03-17T23:49:58+00:00

This is useful for switchdev drivers who are offloading MST states
into hardware. As an example, a driver may wish to flush the FDB for a
port when it transitions from forwarding to blocking - which means
that the previous state must be discoverable.

Signed-off-by: Tobias Waldekranz 
Reviewed-by: Vladimir Oltean 
Acked-by: Nikolay Aleksandrov 
Signed-off-by: Jakub Kicinski

net: bridge: mst: Add helper to check if MST is enabled

2022-03-17T23:49:58+00:00

This is useful for switchdev drivers that might want to refuse to join
a bridge where MST is enabled, if the hardware can't support it.

Signed-off-by: Tobias Waldekranz 
Reviewed-by: Vladimir Oltean 
Acked-by: Nikolay Aleksandrov 
Signed-off-by: Jakub Kicinski

net: bridge: mst: Add helper to map an MSTI to a VID set

2022-03-17T23:49:58+00:00

br_mst_get_info answers the question: "On this bridge, which VIDs are
mapped to the given MSTI?"

This is useful in switchdev drivers, which might have to fan-out
operations, relating to an MSTI, per VLAN.

An example: When a port's MST state changes from forwarding to
blocking, a driver may choose to flush the dynamic FDB entries on that
port to get faster reconvergence of the network, but this should only
be done in the VLANs that are managed by the MSTI in question.

Signed-off-by: Tobias Waldekranz 
Reviewed-by: Vladimir Oltean 
Acked-by: Nikolay Aleksandrov 
Signed-off-by: Jakub Kicinski