@@ -122,7 +122,8 @@ static int br_handle_local_finish(struct sk_buff *skb){structnet_bridge_port*p=br_port_get_rcu(skb->dev);-br_fdb_update(p->br,p,eth_hdr(skb)->h_source);+if(p)+br_fdb_update(p->br,p,eth_hdr(skb)->h_source);return0;/* process further */}
@@ -160,6 +161,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)returnRX_HANDLER_CONSUMED;p=br_port_get_rcu(skb->dev);+if(!p)+gotodrop;if(unlikely(is_link_local(dest))){/* Pause frames shouldn't be passed up by driver anyway */
From: Eric Dumazet <hidden> Date: 2013-06-20 04:55:35
On Thu, 2013-06-20 at 11:08 +0800, xiaoming gao wrote:
From: newtongao <redacted>
Date: Wed, 19 Jun 2013 14:58:33 +0800
Subject: [PATCH] net bridge: add null pointer check,fix panic
in kernel 3.0, br_port_get_rcu() may return NULL when network interface be deleting from bridge,
but in function br_handle_frame and br_handle_local_finish, the pointer didn't be checked before using,
so all br_port_get_rcu callers must do null check,or there occurs the null pointer panic.
kernel 3.4 also has this bug,i have verified.
mainline kernel still did not check br_port_get_rcu()'s NULL pointer, but i have not tested it yet.
Please check current version before sending a patch.
This was most probably fixed in commit 00cfec37484761a44
("net: add a synchronize_net() in netdev_rx_handler_unregister()")
Thanks
On Thu, 2013-06-20 at 11:08 +0800, xiaoming gao wrote:
quoted
From: newtongao <redacted>
Date: Wed, 19 Jun 2013 14:58:33 +0800
Subject: [PATCH] net bridge: add null pointer check,fix panic
in kernel 3.0, br_port_get_rcu() may return NULL when network interface be deleting from bridge,
but in function br_handle_frame and br_handle_local_finish, the pointer didn't be checked before using,
so all br_port_get_rcu callers must do null check,or there occurs the null pointer panic.
kernel 3.4 also has this bug,i have verified.
mainline kernel still did not check br_port_get_rcu()'s NULL pointer, but i have not tested it yet.
Please check current version before sending a patch.
This was most probably fixed in commit 00cfec37484761a44
("net: add a synchronize_net() in netdev_rx_handler_unregister()")
Thanks
HI Eric
the problem is as follow:
br_del_if()-->del_nbp():
list_del_rcu(&p->list);
dev->priv_flags &= ~IFF_BRIDGE_PORT;
------>at this point, the nic be deleting still have rx_handler , so , may in br_handle_frame()
------>br_port_exists() will return false,so br_get_port_rcu() will return NULL
------>so in br_handle_frame , there will be a null panic.
netdev_rx_handler_unregister(dev);
synchronize_net();
i have checked commit 00cfec37484761a44, i think it didn't fix this bug..
thanks.
From: Eric Dumazet <hidden> Date: 2013-06-20 07:29:10
On Thu, 2013-06-20 at 15:00 +0800, xiaoming gao wrote:
HI Eric
the problem is as follow:
br_del_if()-->del_nbp():
list_del_rcu(&p->list);
dev->priv_flags &= ~IFF_BRIDGE_PORT;
------>at this point, the nic be deleting still have rx_handler , so , may in br_handle_frame()
------>br_port_exists() will return false,so br_get_port_rcu() will return NULL
------>so in br_handle_frame , there will be a null panic.
netdev_rx_handler_unregister(dev);
synchronize_net();
This code is no longer like that in current tree.
Check commit 4a0b5ec12f0ffc3024616e6dc62cf8a04c54edcd
("bridge: remove a redundant synchronize_net()")
i have checked commit 00cfec37484761a44, i think it didn't fix this bug..
I claim adding NULL tests is not needed in the fast path, it was clearly
stated in the changelog.
I would change the dismantle path to make sure br_get_port_rcu() does
not return NULL in the fast path, and remove the test on FF_BRIDGE_PORT
Try something like that :
On Thu, 2013-06-20 at 15:00 +0800, xiaoming gao wrote:
quoted
HI Eric
the problem is as follow:
br_del_if()-->del_nbp():
list_del_rcu(&p->list);
dev->priv_flags &= ~IFF_BRIDGE_PORT;
------>at this point, the nic be deleting still have rx_handler , so , may in br_handle_frame()
------>br_port_exists() will return false,so br_get_port_rcu() will return NULL
------>so in br_handle_frame , there will be a null panic.
netdev_rx_handler_unregister(dev);
synchronize_net();
This code is no longer like that in current tree.
Check commit 4a0b5ec12f0ffc3024616e6dc62cf8a04c54edcd
("bridge: remove a redundant synchronize_net()")
quoted
i have checked commit 00cfec37484761a44, i think it didn't fix this bug..
I claim adding NULL tests is not needed in the fast path, it was clearly
stated in the changelog.
I would change the dismantle path to make sure br_get_port_rcu() does
not return NULL in the fast path, and remove the test on FF_BRIDGE_PORT
Try something like that :
if you remove the test on FF_BRIDGE_PORT, and br_port_get_rcu never returns NULL, the problem is fixed.
but the codes in mainline is still bugged, am i right??
by the way, kernel-stable 3.0 and 3.4 tree also have this bug, and is very easily to reproduce.
From: Eric Dumazet <hidden> Date: 2013-06-20 08:14:10
On Thu, 2013-06-20 at 15:47 +0800, xiaoming gao wrote:
if you remove the test on FF_BRIDGE_PORT, and br_port_get_rcu never returns NULL, the problem is fixed.
but the codes in mainline is still bugged, am i right??
by the way, kernel-stable 3.0 and 3.4 tree also have this bug, and is very easily to reproduce.
Commit 00cfec37484761a4 has to be backported anyway, if not already
backported.
I would rather fix things properly, instead of adding defensive code.
From: Alexander Y. Fomichev <hidden> Date: 2013-11-11 10:27:32
On Thu, Jun 20, 2013 at 11:29 AM, Eric Dumazet [off-list ref] wrote:
quoted hunk
On Thu, 2013-06-20 at 15:00 +0800, xiaoming gao wrote:
quoted
HI Eric
the problem is as follow:
br_del_if()-->del_nbp():
list_del_rcu(&p->list);
dev->priv_flags &= ~IFF_BRIDGE_PORT;
------>at this point, the nic be deleting still have rx_handler , so , may in br_handle_frame()
------>br_port_exists() will return false,so br_get_port_rcu() will return NULL
------>so in br_handle_frame , there will be a null panic.
netdev_rx_handler_unregister(dev);
synchronize_net();
This code is no longer like that in current tree.
Check commit 4a0b5ec12f0ffc3024616e6dc62cf8a04c54edcd
("bridge: remove a redundant synchronize_net()")
quoted
i have checked commit 00cfec37484761a44, i think it didn't fix this bug..
I claim adding NULL tests is not needed in the fast path, it was clearly
stated in the changelog.
I would change the dismantle path to make sure br_get_port_rcu() does
not return NULL in the fast path, and remove the test on FF_BRIDGE_PORT
Try something like that :
I claim adding NULL tests is not needed in the fast path, it was clearly
stated in the changelog.
Hello,
This commit makes trouble for current STP.
Two days ago i tried to switch to 3.10.18 and i've caught "bad magic"
on uninitialized br->lock:
./net/bridge/br_stp_bpdu.c +158 in br_stp_rcv (trace attached):
p = br_port_get_rcu(dev);
br = p->br;
spin_lock(&br->lock); <- here
-----------------------------------------------
Bisect pointed to this commit
(linux-stable: 960b8e5018a552f62cfbc0dfe94be7b6ba178f13)
(mainline 716ec052d2280d511e10e90ad54a86f5b5d4dcc2)
As far as i can see this happens when:
a) bridge module had been loaded but there was no bridge interface,
br->lock had not been initialized.
b) interface had been in promiscuous mod (tcpdump)
c) stp broadcasts 01:80:c2:00:00:00 coming to this iface
(llc_rcv drops PACKET_OTHERHOST to protect us in promiscuous mode
but seems like not a broadcasts)
d) and finally rx_handler_data had been initialised for this interface
( by macvlan in my case)
It seems like STP needs its own IFF_BRIDGE_PORT check.
probably an easiest option to check it in br_stp_rcv as before (or
probably in llc_rcv)...
--
Best regards.
Alexander Y. Fomichev [off-list ref]