<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/bridge, branch linux-4.9.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>netfilter: br_netfilter: Drop dst references before setting.</title>
<updated>2022-09-15T10:39:46+00:00</updated>
<author>
<name>Harsh Modi</name>
<email>harshmodi@google.com</email>
</author>
<published>2022-08-31T05:36:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=92c4fe831a72c432b66193699a7664fa6a229e50'/>
<id>92c4fe831a72c432b66193699a7664fa6a229e50</id>
<content type='text'>
[ Upstream commit d047283a7034140ea5da759a494fd2274affdd46 ]

The IPv6 path already drops dst in the daddr changed case, but the IPv4
path does not. This change makes the two code paths consistent.

Further, it is possible that there is already a metadata_dst allocated from
ingress that might already be attached to skbuff-&gt;dst while following
the bridge path. If it is not released before setting a new
metadata_dst, it will be leaked. This is similar to what is done in
bpf_set_tunnel_key() or ip6_route_input().

It is important to note that the memory being leaked is not the dst
being set in the bridge code, but rather memory allocated from some
other code path that is not being freed correctly before the skb dst is
overwritten.

An example of the leakage fixed by this commit found using kmemleak:

unreferenced object 0xffff888010112b00 (size 256):
  comm "softirq", pid 0, jiffies 4294762496 (age 32.012s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 80 16 f1 83 ff ff ff ff  ................
    e1 4e f6 82 ff ff ff ff 00 00 00 00 00 00 00 00  .N..............
  backtrace:
    [&lt;00000000d79567ea&gt;] metadata_dst_alloc+0x1b/0xe0
    [&lt;00000000be113e13&gt;] udp_tun_rx_dst+0x174/0x1f0
    [&lt;00000000a36848f4&gt;] geneve_udp_encap_recv+0x350/0x7b0
    [&lt;00000000d4afb476&gt;] udp_queue_rcv_one_skb+0x380/0x560
    [&lt;00000000ac064aea&gt;] udp_unicast_rcv_skb+0x75/0x90
    [&lt;000000009a8ee8c5&gt;] ip_protocol_deliver_rcu+0xd8/0x230
    [&lt;00000000ef4980bb&gt;] ip_local_deliver_finish+0x7a/0xa0
    [&lt;00000000d7533c8c&gt;] __netif_receive_skb_one_core+0x89/0xa0
    [&lt;00000000a879497d&gt;] process_backlog+0x93/0x190
    [&lt;00000000e41ade9f&gt;] __napi_poll+0x28/0x170
    [&lt;00000000b4c0906b&gt;] net_rx_action+0x14f/0x2a0
    [&lt;00000000b20dd5d4&gt;] __do_softirq+0xf4/0x305
    [&lt;000000003a7d7e15&gt;] __irq_exit_rcu+0xc3/0x140
    [&lt;00000000968d39a2&gt;] sysvec_apic_timer_interrupt+0x9e/0xc0
    [&lt;000000009e920794&gt;] asm_sysvec_apic_timer_interrupt+0x16/0x20
    [&lt;000000008942add0&gt;] native_safe_halt+0x13/0x20

Florian Westphal says: "Original code was likely fine because nothing
ever did set a skb-&gt;dst entry earlier than bridge in those days."

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Harsh Modi &lt;harshmodi@google.com&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d047283a7034140ea5da759a494fd2274affdd46 ]

The IPv6 path already drops dst in the daddr changed case, but the IPv4
path does not. This change makes the two code paths consistent.

Further, it is possible that there is already a metadata_dst allocated from
ingress that might already be attached to skbuff-&gt;dst while following
the bridge path. If it is not released before setting a new
metadata_dst, it will be leaked. This is similar to what is done in
bpf_set_tunnel_key() or ip6_route_input().

It is important to note that the memory being leaked is not the dst
being set in the bridge code, but rather memory allocated from some
other code path that is not being freed correctly before the skb dst is
overwritten.

An example of the leakage fixed by this commit found using kmemleak:

unreferenced object 0xffff888010112b00 (size 256):
  comm "softirq", pid 0, jiffies 4294762496 (age 32.012s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 80 16 f1 83 ff ff ff ff  ................
    e1 4e f6 82 ff ff ff ff 00 00 00 00 00 00 00 00  .N..............
  backtrace:
    [&lt;00000000d79567ea&gt;] metadata_dst_alloc+0x1b/0xe0
    [&lt;00000000be113e13&gt;] udp_tun_rx_dst+0x174/0x1f0
    [&lt;00000000a36848f4&gt;] geneve_udp_encap_recv+0x350/0x7b0
    [&lt;00000000d4afb476&gt;] udp_queue_rcv_one_skb+0x380/0x560
    [&lt;00000000ac064aea&gt;] udp_unicast_rcv_skb+0x75/0x90
    [&lt;000000009a8ee8c5&gt;] ip_protocol_deliver_rcu+0xd8/0x230
    [&lt;00000000ef4980bb&gt;] ip_local_deliver_finish+0x7a/0xa0
    [&lt;00000000d7533c8c&gt;] __netif_receive_skb_one_core+0x89/0xa0
    [&lt;00000000a879497d&gt;] process_backlog+0x93/0x190
    [&lt;00000000e41ade9f&gt;] __napi_poll+0x28/0x170
    [&lt;00000000b4c0906b&gt;] net_rx_action+0x14f/0x2a0
    [&lt;00000000b20dd5d4&gt;] __do_softirq+0xf4/0x305
    [&lt;000000003a7d7e15&gt;] __irq_exit_rcu+0xc3/0x140
    [&lt;00000000968d39a2&gt;] sysvec_apic_timer_interrupt+0x9e/0xc0
    [&lt;000000009e920794&gt;] asm_sysvec_apic_timer_interrupt+0x16/0x20
    [&lt;000000008942add0&gt;] native_safe_halt+0x13/0x20

Florian Westphal says: "Original code was likely fine because nothing
ever did set a skb-&gt;dst entry earlier than bridge in those days."

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Harsh Modi &lt;harshmodi@google.com&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: bridge: add support for pppoe filtering</title>
<updated>2022-01-27T07:47:33+00:00</updated>
<author>
<name>Florian Westphal</name>
<email>fw@strlen.de</email>
</author>
<published>2021-11-23T11:50:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c9bfd3607aad829ba1b9270b3a20e6fd6653e707'/>
<id>c9bfd3607aad829ba1b9270b3a20e6fd6653e707</id>
<content type='text'>
[ Upstream commit 28b78ecffea8078d81466b2e01bb5a154509f1ba ]

This makes 'bridge-nf-filter-pppoe-tagged' sysctl work for
bridged traffic.

Looking at the original commit it doesn't appear this ever worked:

 static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff **pskb,
[..]
        if (skb-&gt;protocol == htons(ETH_P_8021Q)) {
                skb_pull(skb, VLAN_HLEN);
                skb-&gt;network_header += VLAN_HLEN;
+       } else if (skb-&gt;protocol == htons(ETH_P_PPP_SES)) {
+               skb_pull(skb, PPPOE_SES_HLEN);
+               skb-&gt;network_header += PPPOE_SES_HLEN;
        }
 [..]
	NF_HOOK(... POST_ROUTING, ...)

... but the adjusted offsets are never restored.

The alternative would be to rip this code out for good,
but otoh we'd have to keep this anyway for the vlan handling
(which works because vlan tag info is in the skb, not the packet
 payload).

Reported-and-tested-by: Amish Chana &lt;amish@3g.co.za&gt;
Fixes: 516299d2f5b6f97 ("[NETFILTER]: bridge-nf: filter bridged IPv4/IPv6 encapsulated in pppoe traffic")
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 28b78ecffea8078d81466b2e01bb5a154509f1ba ]

This makes 'bridge-nf-filter-pppoe-tagged' sysctl work for
bridged traffic.

Looking at the original commit it doesn't appear this ever worked:

 static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff **pskb,
[..]
        if (skb-&gt;protocol == htons(ETH_P_8021Q)) {
                skb_pull(skb, VLAN_HLEN);
                skb-&gt;network_header += VLAN_HLEN;
+       } else if (skb-&gt;protocol == htons(ETH_P_PPP_SES)) {
+               skb_pull(skb, PPPOE_SES_HLEN);
+               skb-&gt;network_header += PPPOE_SES_HLEN;
        }
 [..]
	NF_HOOK(... POST_ROUTING, ...)

... but the adjusted offsets are never restored.

The alternative would be to rip this code out for good,
but otoh we'd have to keep this anyway for the vlan handling
(which works because vlan tag info is in the skb, not the packet
 payload).

Reported-and-tested-by: Amish Chana &lt;amish@3g.co.za&gt;
Fixes: 516299d2f5b6f97 ("[NETFILTER]: bridge-nf: filter bridged IPv4/IPv6 encapsulated in pppoe traffic")
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: bridge: use nla_total_size_64bit() in br_get_linkxstats_size()</title>
<updated>2021-10-17T08:05:39+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2021-10-05T01:05:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=49c85ce900ff33de115fabdd06983e955b093243'/>
<id>49c85ce900ff33de115fabdd06983e955b093243</id>
<content type='text'>
[ Upstream commit dbe0b88064494b7bb6a9b2aa7e085b14a3112d44 ]

bridge_fill_linkxstats() is using nla_reserve_64bit().

We must use nla_total_size_64bit() instead of nla_total_size()
for corresponding data structure.

Fixes: 1080ab95e3c7 ("net: bridge: add support for IGMP/MLD stats and export them via netlink")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Cc: Vivien Didelot &lt;vivien.didelot@gmail.com&gt;
Acked-by: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit dbe0b88064494b7bb6a9b2aa7e085b14a3112d44 ]

bridge_fill_linkxstats() is using nla_reserve_64bit().

We must use nla_total_size_64bit() instead of nla_total_size()
for corresponding data structure.

Fixes: 1080ab95e3c7 ("net: bridge: add support for IGMP/MLD stats and export them via netlink")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Cc: Vivien Didelot &lt;vivien.didelot@gmail.com&gt;
Acked-by: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: bridge: fix memleak in br_add_if()</title>
<updated>2021-08-26T12:37:22+00:00</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2021-08-09T13:20:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=59ef9eb17186ebc99108ef7429e6c9da38c86a29'/>
<id>59ef9eb17186ebc99108ef7429e6c9da38c86a29</id>
<content type='text'>
[ Upstream commit 519133debcc19f5c834e7e28480b60bdc234fe02 ]

I got a memleak report:

BUG: memory leak
unreferenced object 0x607ee521a658 (size 240):
comm "syz-executor.0", pid 955, jiffies 4294780569 (age 16.449s)
hex dump (first 32 bytes, cpu 1):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[&lt;00000000d830ea5a&gt;] br_multicast_add_port+0x1c2/0x300 net/bridge/br_multicast.c:1693
[&lt;00000000274d9a71&gt;] new_nbp net/bridge/br_if.c:435 [inline]
[&lt;00000000274d9a71&gt;] br_add_if+0x670/0x1740 net/bridge/br_if.c:611
[&lt;0000000012ce888e&gt;] do_set_master net/core/rtnetlink.c:2513 [inline]
[&lt;0000000012ce888e&gt;] do_set_master+0x1aa/0x210 net/core/rtnetlink.c:2487
[&lt;0000000099d1cafc&gt;] __rtnl_newlink+0x1095/0x13e0 net/core/rtnetlink.c:3457
[&lt;00000000a01facc0&gt;] rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3488
[&lt;00000000acc9186c&gt;] rtnetlink_rcv_msg+0x369/0xa10 net/core/rtnetlink.c:5550
[&lt;00000000d4aabb9c&gt;] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504
[&lt;00000000bc2e12a3&gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
[&lt;00000000bc2e12a3&gt;] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340
[&lt;00000000e4dc2d0e&gt;] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929
[&lt;000000000d22c8b3&gt;] sock_sendmsg_nosec net/socket.c:654 [inline]
[&lt;000000000d22c8b3&gt;] sock_sendmsg+0x139/0x170 net/socket.c:674
[&lt;00000000e281417a&gt;] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350
[&lt;00000000237aa2ab&gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404
[&lt;000000004f2dc381&gt;] __sys_sendmsg+0xd3/0x190 net/socket.c:2433
[&lt;0000000005feca6c&gt;] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47
[&lt;000000007304477d&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae

On error path of br_add_if(), p-&gt;mcast_stats allocated in
new_nbp() need be freed, or it will be leaked.

Fixes: 1080ab95e3c7 ("net: bridge: add support for IGMP/MLD stats and export them via netlink")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Acked-by: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Link: https://lore.kernel.org/r/20210809132023.978546-1-yangyingliang@huawei.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 519133debcc19f5c834e7e28480b60bdc234fe02 ]

I got a memleak report:

BUG: memory leak
unreferenced object 0x607ee521a658 (size 240):
comm "syz-executor.0", pid 955, jiffies 4294780569 (age 16.449s)
hex dump (first 32 bytes, cpu 1):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[&lt;00000000d830ea5a&gt;] br_multicast_add_port+0x1c2/0x300 net/bridge/br_multicast.c:1693
[&lt;00000000274d9a71&gt;] new_nbp net/bridge/br_if.c:435 [inline]
[&lt;00000000274d9a71&gt;] br_add_if+0x670/0x1740 net/bridge/br_if.c:611
[&lt;0000000012ce888e&gt;] do_set_master net/core/rtnetlink.c:2513 [inline]
[&lt;0000000012ce888e&gt;] do_set_master+0x1aa/0x210 net/core/rtnetlink.c:2487
[&lt;0000000099d1cafc&gt;] __rtnl_newlink+0x1095/0x13e0 net/core/rtnetlink.c:3457
[&lt;00000000a01facc0&gt;] rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3488
[&lt;00000000acc9186c&gt;] rtnetlink_rcv_msg+0x369/0xa10 net/core/rtnetlink.c:5550
[&lt;00000000d4aabb9c&gt;] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504
[&lt;00000000bc2e12a3&gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
[&lt;00000000bc2e12a3&gt;] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340
[&lt;00000000e4dc2d0e&gt;] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929
[&lt;000000000d22c8b3&gt;] sock_sendmsg_nosec net/socket.c:654 [inline]
[&lt;000000000d22c8b3&gt;] sock_sendmsg+0x139/0x170 net/socket.c:674
[&lt;00000000e281417a&gt;] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350
[&lt;00000000237aa2ab&gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404
[&lt;000000004f2dc381&gt;] __sys_sendmsg+0xd3/0x190 net/socket.c:2433
[&lt;0000000005feca6c&gt;] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47
[&lt;000000007304477d&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae

On error path of br_add_if(), p-&gt;mcast_stats allocated in
new_nbp() need be freed, or it will be leaked.

Fixes: 1080ab95e3c7 ("net: bridge: add support for IGMP/MLD stats and export them via netlink")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Acked-by: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Link: https://lore.kernel.org/r/20210809132023.978546-1-yangyingliang@huawei.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: bridge: sync fdb to new unicast-filtering ports</title>
<updated>2021-07-28T07:14:25+00:00</updated>
<author>
<name>Wolfgang Bumiller</name>
<email>w.bumiller@proxmox.com</email>
</author>
<published>2021-07-02T12:07:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ac4ba3721a22df1d94436b553fc0e8fb646f2a74'/>
<id>ac4ba3721a22df1d94436b553fc0e8fb646f2a74</id>
<content type='text'>
commit a019abd8022061b917da767cd1a66ed823724eab upstream.

Since commit 2796d0c648c9 ("bridge: Automatically manage
port promiscuous mode.")
bridges with `vlan_filtering 1` and only 1 auto-port don't
set IFF_PROMISC for unicast-filtering-capable ports.

Normally on port changes `br_manage_promisc` is called to
update the promisc flags and unicast filters if necessary,
but it cannot distinguish between *new* ports and ones
losing their promisc flag, and new ports end up not
receiving the MAC address list.

Fix this by calling `br_fdb_sync_static` in `br_add_if`
after the port promisc flags are updated and the unicast
filter was supposed to have been filled.

Fixes: 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.")
Signed-off-by: Wolfgang Bumiller &lt;w.bumiller@proxmox.com&gt;
Acked-by: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a019abd8022061b917da767cd1a66ed823724eab upstream.

Since commit 2796d0c648c9 ("bridge: Automatically manage
port promiscuous mode.")
bridges with `vlan_filtering 1` and only 1 auto-port don't
set IFF_PROMISC for unicast-filtering-capable ports.

Normally on port changes `br_manage_promisc` is called to
update the promisc flags and unicast filters if necessary,
but it cannot distinguish between *new* ports and ones
losing their promisc flag, and new ports end up not
receiving the MAC address list.

Fix this by calling `br_fdb_sync_static` in `br_add_if`
after the port promisc flags are updated and the unicast
filter was supposed to have been filled.

Fixes: 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.")
Signed-off-by: Wolfgang Bumiller &lt;w.bumiller@proxmox.com&gt;
Acked-by: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: bridge: vlan: fix error return code in __vlan_add()</title>
<updated>2020-12-29T12:44:48+00:00</updated>
<author>
<name>Zhang Changzhong</name>
<email>zhangchangzhong@huawei.com</email>
</author>
<published>2020-12-04T08:48:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5b932ef23f9c4f9214759b265ad0ff75b4ea43c5'/>
<id>5b932ef23f9c4f9214759b265ad0ff75b4ea43c5</id>
<content type='text'>
[ Upstream commit ee4f52a8de2c6f78b01f10b4c330867d88c1653a ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: f8ed289fab84 ("bridge: vlan: use br_vlan_(get|put)_master to deal with refcounts")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Zhang Changzhong &lt;zhangchangzhong@huawei.com&gt;
Acked-by: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Link: https://lore.kernel.org/r/1607071737-33875-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ee4f52a8de2c6f78b01f10b4c330867d88c1653a ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: f8ed289fab84 ("bridge: vlan: use br_vlan_(get|put)_master to deal with refcounts")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Zhang Changzhong &lt;zhangchangzhong@huawei.com&gt;
Acked-by: Nikolay Aleksandrov &lt;nikolay@nvidia.com&gt;
Link: https://lore.kernel.org/r/1607071737-33875-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: bridge: reset skb-&gt;pkt_type after NF_INET_POST_ROUTING traversal</title>
<updated>2020-12-11T12:37:57+00:00</updated>
<author>
<name>Antoine Tenart</name>
<email>atenart@kernel.org</email>
</author>
<published>2020-11-23T17:49:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=10b6f570e0af27f22c019aac04f53a266e0d9c0e'/>
<id>10b6f570e0af27f22c019aac04f53a266e0d9c0e</id>
<content type='text'>
[ Upstream commit 44f64f23bae2f0fad25503bc7ab86cd08d04cd47 ]

Netfilter changes PACKET_OTHERHOST to PACKET_HOST before invoking the
hooks as, while it's an expected value for a bridge, routing expects
PACKET_HOST. The change is undone later on after hook traversal. This
can be seen with pairs of functions updating skb&gt;pkt_type and then
reverting it to its original value:

For hook NF_INET_PRE_ROUTING:
  setup_pre_routing / br_nf_pre_routing_finish

For hook NF_INET_FORWARD:
  br_nf_forward_ip / br_nf_forward_finish

But the third case where netfilter does this, for hook
NF_INET_POST_ROUTING, the packet type is changed in br_nf_post_routing
but never reverted. A comment says:

  /* We assume any code from br_dev_queue_push_xmit onwards doesn't care
   * about the value of skb-&gt;pkt_type. */

But when having a tunnel (say vxlan) attached to a bridge we have the
following call trace:

  br_nf_pre_routing
  br_nf_pre_routing_ipv6
     br_nf_pre_routing_finish
  br_nf_forward_ip
     br_nf_forward_finish
  br_nf_post_routing           &lt;- pkt_type is updated to PACKET_HOST
     br_nf_dev_queue_xmit      &lt;- but not reverted to its original value
  vxlan_xmit
     vxlan_xmit_one
        skb_tunnel_check_pmtu  &lt;- a check on pkt_type is performed

In this specific case, this creates issues such as when an ICMPv6 PTB
should be sent back. When CONFIG_BRIDGE_NETFILTER is enabled, the PTB
isn't sent (as skb_tunnel_check_pmtu checks if pkt_type is PACKET_HOST
and returns early).

If the comment is right and no one cares about the value of
skb-&gt;pkt_type after br_dev_queue_push_xmit (which isn't true), resetting
it to its original value should be safe.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Antoine Tenart &lt;atenart@kernel.org&gt;
Reviewed-by: Florian Westphal &lt;fw@strlen.de&gt;
Link: https://lore.kernel.org/r/20201123174902.622102-1-atenart@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 44f64f23bae2f0fad25503bc7ab86cd08d04cd47 ]

Netfilter changes PACKET_OTHERHOST to PACKET_HOST before invoking the
hooks as, while it's an expected value for a bridge, routing expects
PACKET_HOST. The change is undone later on after hook traversal. This
can be seen with pairs of functions updating skb&gt;pkt_type and then
reverting it to its original value:

For hook NF_INET_PRE_ROUTING:
  setup_pre_routing / br_nf_pre_routing_finish

For hook NF_INET_FORWARD:
  br_nf_forward_ip / br_nf_forward_finish

But the third case where netfilter does this, for hook
NF_INET_POST_ROUTING, the packet type is changed in br_nf_post_routing
but never reverted. A comment says:

  /* We assume any code from br_dev_queue_push_xmit onwards doesn't care
   * about the value of skb-&gt;pkt_type. */

But when having a tunnel (say vxlan) attached to a bridge we have the
following call trace:

  br_nf_pre_routing
  br_nf_pre_routing_ipv6
     br_nf_pre_routing_finish
  br_nf_forward_ip
     br_nf_forward_finish
  br_nf_post_routing           &lt;- pkt_type is updated to PACKET_HOST
     br_nf_dev_queue_xmit      &lt;- but not reverted to its original value
  vxlan_xmit
     vxlan_xmit_one
        skb_tunnel_check_pmtu  &lt;- a check on pkt_type is performed

In this specific case, this creates issues such as when an ICMPv6 PTB
should be sent back. When CONFIG_BRIDGE_NETFILTER is enabled, the PTB
isn't sent (as skb_tunnel_check_pmtu checks if pkt_type is PACKET_HOST
and returns early).

If the comment is right and no one cares about the value of
skb-&gt;pkt_type after br_dev_queue_push_xmit (which isn't true), resetting
it to its original value should be safe.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Antoine Tenart &lt;atenart@kernel.org&gt;
Reviewed-by: Florian Westphal &lt;fw@strlen.de&gt;
Link: https://lore.kernel.org/r/20201123174902.622102-1-atenart@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: bridge: add missing counters to ndo_get_stats64 callback</title>
<updated>2020-11-24T12:02:55+00:00</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2020-11-13T09:27:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=41456415b831c1df8da98014e113c4f4a3db22a8'/>
<id>41456415b831c1df8da98014e113c4f4a3db22a8</id>
<content type='text'>
[ Upstream commit 7a30ecc9237681bb125cbd30eee92bef7e86293d ]

In br_forward.c and br_input.c fields dev-&gt;stats.tx_dropped and
dev-&gt;stats.multicast are populated, but they are ignored in
ndo_get_stats64.

Fixes: 28172739f0a2 ("net: fix 64 bit counters on 32 bit arches")
Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Link: https://lore.kernel.org/r/58ea9963-77ad-a7cf-8dfd-fc95ab95f606@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7a30ecc9237681bb125cbd30eee92bef7e86293d ]

In br_forward.c and br_input.c fields dev-&gt;stats.tx_dropped and
dev-&gt;stats.multicast are populated, but they are ignored in
ndo_get_stats64.

Fixes: 28172739f0a2 ("net: fix 64 bit counters on 32 bit arches")
Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Link: https://lore.kernel.org/r/58ea9963-77ad-a7cf-8dfd-fc95ab95f606@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: nft_reject_bridge: enable reject with bridge vlan</title>
<updated>2020-06-03T06:16:45+00:00</updated>
<author>
<name>Michael Braun</name>
<email>michael-dev@fami-braun.de</email>
</author>
<published>2020-05-06T09:46:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b614b8642fb89de42585b80b0a2485002a2d47da'/>
<id>b614b8642fb89de42585b80b0a2485002a2d47da</id>
<content type='text'>
commit e9c284ec4b41c827f4369973d2792992849e4fa5 upstream.

Currently, using the bridge reject target with tagged packets
results in untagged packets being sent back.

Fix this by mirroring the vlan id as well.

Fixes: 85f5b3086a04 ("netfilter: bridge: add reject support")
Signed-off-by: Michael Braun &lt;michael-dev@fami-braun.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e9c284ec4b41c827f4369973d2792992849e4fa5 upstream.

Currently, using the bridge reject target with tagged packets
results in untagged packets being sent back.

Fix this by mirroring the vlan id as well.

Fixes: 85f5b3086a04 ("netfilter: bridge: add reject support")
Signed-off-by: Michael Braun &lt;michael-dev@fami-braun.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: ebtables: CONFIG_COMPAT: reject trailing data after last rule</title>
<updated>2020-01-29T09:24:24+00:00</updated>
<author>
<name>Florian Westphal</name>
<email>fw@strlen.de</email>
</author>
<published>2019-05-05T16:47:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=82366de36f1f468daa0856da5f424d50e9b33d5a'/>
<id>82366de36f1f468daa0856da5f424d50e9b33d5a</id>
<content type='text'>
[ Upstream commit 680f6af5337c98d116e4f127cea7845339dba8da ]

If userspace provides a rule blob with trailing data after last target,
we trigger a splat, then convert ruleset to 64bit format (with trailing
data), then pass that to do_replace_finish() which then returns -EINVAL.

Erroring out right away avoids the splat plus unneeded translation and
error unwind.

Fixes: 81e675c227ec ("netfilter: ebtables: add CONFIG_COMPAT support")
Reported-by: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 680f6af5337c98d116e4f127cea7845339dba8da ]

If userspace provides a rule blob with trailing data after last target,
we trigger a splat, then convert ruleset to 64bit format (with trailing
data), then pass that to do_replace_finish() which then returns -EINVAL.

Erroring out right away avoids the splat plus unneeded translation and
error unwind.

Fixes: 81e675c227ec ("netfilter: ebtables: add CONFIG_COMPAT support")
Reported-by: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
