From: xiaoming gao <gxm.linux.kernel@gmail.com>
To: stephen@networkplumber.org, davem@davemloft.net,
bridge@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [Bridge] [PATCH] net bridge: add null pointer check, fix panic
Date: Thu, 20 Jun 2013 11:08:11 +0800 [thread overview]
Message-ID: <51C2721B.9050603@gmail.com> (raw)
In-Reply-To: <51C2710D.2060405@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4353 bytes --]
From: newtongao <newtongao@tencent.com>
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.
method to reproduce null pointer panic:
1. in function del_nbp,amplify the gap between "dev->priv_flags &= ~IFF_BRIDGE_PORT;" and "netdev_rx_handler_unregister(dev);" , such as add new line "while(1);".
2. create net bridge testbr and bind some network interface(e.g. testif) on it.
3. send packets to testif frequetly,such as ping testif.
4. brctl delif testbr testif.
backtrace:
[1002130.426411] FS: 00007f2235153700(0000) GS:ffff88007b020000(0000) knlGS:0000000000000000
[1002130.524656] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[1002130.594931] CR2: 0000000000000021 CR3: 0000000001dc7000 CR4: 0000000000002660
[1002130.681798] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[1002130.768654] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[1002130.855525] Process ksoftirqd/1 (pid: 9, threadinfo ffff880062642000, task ffff880062640800)
[1002130.957868] Stack:
[1002130.983758] 0000000080000000 ffff88007bc06a40 ffff88005e3c6c80 ffffffff81901d10
[1002131.073887] ffff88005efc2000 0000000000000001 ffff880062643bf0 ffffffff818497d9
[1002131.163945] ffff88006147e090 0000000000000020 ffff88007bc06a40 ffff88005e3c6c80
[1002131.254023] Call Trace:
[1002131.285086] [<ffffffff81901d10>] ? br_handle_frame_finish+0x2b0/0x2b0
[1002131.364677] [<ffffffff818497d9>] __netif_receive_skb+0x109/0x4a0
[1002131.439081] [<ffffffff81849b12>] __netif_receive_skb+0x442/0x4a0
[1002131.513493] [<ffffffff810e3a6e>] ? __kmalloc_node+0x3e/0x50
[1002131.582744] [<ffffffff8184b7d8>] netif_receive_skb+0x78/0x80
[1002131.653053] [<ffffffff8184b928>] napi_skb_finish+0x48/0x60
[1002131.721269] [<ffffffff8184bf1d>] napi_gro_receive+0xfd/0x130
[1002131.791551] [<ffffffff8192b2f6>] vlan_gro_receive+0x16/0x20
[1002131.860796] [<ffffffff816a41d1>] igb_poll+0x6f1/0xdc0
[1002131.923871] [<ffffffff8196c0d5>] ? __schedule+0x2e5/0x810
[1002131.991071] [<ffffffff8196e38b>] ? _raw_spin_lock_irq+0xb/0x30
[1002132.063421] [<ffffffff8184c0c1>] net_rx_action+0xa1/0x1d0
[1002132.130619] [<ffffffff81057449>] __do_softirq+0x99/0x130
[1002132.196803] [<ffffffff8105759a>] run_ksoftirqd+0xba/0x170
[1002132.264000] [<ffffffff810574e0>] ? __do_softirq+0x130/0x130
[1002132.333258] [<ffffffff8106d306>] kthread+0x96/0xa0
[1002132.393224] [<ffffffff8196ffe4>] kernel_thread_helper+0x4/0x10
[1002132.465580] [<ffffffff8196f0f6>] ? int_ret_from_sys_call+0x7/0x1b
[1002132.541016] [<ffffffff8196e8a1>] ? retint_restore_args+0x5/0x6
[1002132.613368] [<ffffffff8196ffe0>] ? gs_change+0x13/0x13
[1002132.677466] Code: 02 f6 81 a5 01 00 00 40 48 8b 81 e0 02 00 00 89 d6 4c 0f 45 f0 48 8b 05 50 76 20 00 66 33 70 04 66 f7 c6 ff f0 0f 84 d0 00 00 00
[1002132.835500] 0f b6 46 21 3c 02 74 50 3c 03 0f 85 60 ff ff ff 48 8b 05 e1
[1002132.920864] RIP [<ffffffff81901e17>] br_handle_frame+0x107/0x260
[1002132.995296] RSP <ffff880062643b50>
[1002133.038735] CR2: 0000000000000021
Signed-off-by: Xiaoming Gao <newtongao@tencent.com>
---
net/bridge/br_input.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f06ee39..c8b365f 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -122,7 +122,8 @@ static int br_handle_local_finish(struct sk_buff *skb)
{
struct net_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);
return 0; /* process further */
}
@@ -160,6 +161,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
return RX_HANDLER_CONSUMED;
p = br_port_get_rcu(skb->dev);
+ if (!p)
+ goto drop;
if (unlikely(is_link_local(dest))) {
/* Pause frames shouldn't be passed up by driver anyway */
--
1.7.1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-net-bridge-add-null-pointer-check.patch --]
[-- Type: text/plain; charset=gb18030; name="0001-net-bridge-add-null-pointer-check.patch", Size: 4422 bytes --]
From 2b39c4ccd812723891117184b297f6886dcfd976 Mon Sep 17 00:00:00 2001
From: newtongao <newtongao@tencent.com>
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.
method to reproduce null pointer panic:
1. in function del_nbp,amplify the gap between "dev->priv_flags &= ~IFF_BRIDGE_PORT;" and "netdev_rx_handler_unregister(dev);" , such as add new line "while(1);".
2. create net bridge testbr and bind some network interface(e.g. testif) on it.
3. send packets to testif frequetly,such as ping testif.
4. brctl delif testbr testif.
backtrace:
[1002130.426411] FS: 00007f2235153700(0000) GS:ffff88007b020000(0000) knlGS:0000000000000000
[1002130.524656] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[1002130.594931] CR2: 0000000000000021 CR3: 0000000001dc7000 CR4: 0000000000002660
[1002130.681798] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[1002130.768654] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[1002130.855525] Process ksoftirqd/1 (pid: 9, threadinfo ffff880062642000, task ffff880062640800)
[1002130.957868] Stack:
[1002130.983758] 0000000080000000 ffff88007bc06a40 ffff88005e3c6c80 ffffffff81901d10
[1002131.073887] ffff88005efc2000 0000000000000001 ffff880062643bf0 ffffffff818497d9
[1002131.163945] ffff88006147e090 0000000000000020 ffff88007bc06a40 ffff88005e3c6c80
[1002131.254023] Call Trace:
[1002131.285086] [<ffffffff81901d10>] ? br_handle_frame_finish+0x2b0/0x2b0
[1002131.364677] [<ffffffff818497d9>] __netif_receive_skb+0x109/0x4a0
[1002131.439081] [<ffffffff81849b12>] __netif_receive_skb+0x442/0x4a0
[1002131.513493] [<ffffffff810e3a6e>] ? __kmalloc_node+0x3e/0x50
[1002131.582744] [<ffffffff8184b7d8>] netif_receive_skb+0x78/0x80
[1002131.653053] [<ffffffff8184b928>] napi_skb_finish+0x48/0x60
[1002131.721269] [<ffffffff8184bf1d>] napi_gro_receive+0xfd/0x130
[1002131.791551] [<ffffffff8192b2f6>] vlan_gro_receive+0x16/0x20
[1002131.860796] [<ffffffff816a41d1>] igb_poll+0x6f1/0xdc0
[1002131.923871] [<ffffffff8196c0d5>] ? __schedule+0x2e5/0x810
[1002131.991071] [<ffffffff8196e38b>] ? _raw_spin_lock_irq+0xb/0x30
[1002132.063421] [<ffffffff8184c0c1>] net_rx_action+0xa1/0x1d0
[1002132.130619] [<ffffffff81057449>] __do_softirq+0x99/0x130
[1002132.196803] [<ffffffff8105759a>] run_ksoftirqd+0xba/0x170
[1002132.264000] [<ffffffff810574e0>] ? __do_softirq+0x130/0x130
[1002132.333258] [<ffffffff8106d306>] kthread+0x96/0xa0
[1002132.393224] [<ffffffff8196ffe4>] kernel_thread_helper+0x4/0x10
[1002132.465580] [<ffffffff8196f0f6>] ? int_ret_from_sys_call+0x7/0x1b
[1002132.541016] [<ffffffff8196e8a1>] ? retint_restore_args+0x5/0x6
[1002132.613368] [<ffffffff8196ffe0>] ? gs_change+0x13/0x13
[1002132.677466] Code: 02 f6 81 a5 01 00 00 40 48 8b 81 e0 02 00 00 89 d6 4c 0f 45 f0 48 8b 05 50 76 20 00 66 33 70 04 66 f7 c6 ff f0 0f 84 d0 00 00 00
[1002132.835500] 0f b6 46 21 3c 02 74 50 3c 03 0f 85 60 ff ff ff 48 8b 05 e1
[1002132.920864] RIP [<ffffffff81901e17>] br_handle_frame+0x107/0x260
[1002132.995296] RSP <ffff880062643b50>
[1002133.038735] CR2: 0000000000000021
Signed-off-by: Xiaoming Gao <newtongao@tencent.com>
---
net/bridge/br_input.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f06ee39..c8b365f 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -122,7 +122,8 @@ static int br_handle_local_finish(struct sk_buff *skb)
{
struct net_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);
return 0; /* process further */
}
@@ -160,6 +161,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
return RX_HANDLER_CONSUMED;
p = br_port_get_rcu(skb->dev);
+ if (!p)
+ goto drop;
if (unlikely(is_link_local(dest))) {
/* Pause frames shouldn't be passed up by driver anyway */
--
1.7.1
WARNING: multiple messages have this Message-ID (diff)
From: xiaoming gao <gxm.linux.kernel@gmail.com>
To: stephen@networkplumber.org, davem@davemloft.net,
bridge@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH] net bridge: add null pointer check, fix panic
Date: Thu, 20 Jun 2013 11:08:11 +0800 [thread overview]
Message-ID: <51C2721B.9050603@gmail.com> (raw)
In-Reply-To: <51C2710D.2060405@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4353 bytes --]
From: newtongao <newtongao@tencent.com>
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.
method to reproduce null pointer panic:
1. in function del_nbp,amplify the gap between "dev->priv_flags &= ~IFF_BRIDGE_PORT;" and "netdev_rx_handler_unregister(dev);" , such as add new line "while(1);".
2. create net bridge testbr and bind some network interface(e.g. testif) on it.
3. send packets to testif frequetly,such as ping testif.
4. brctl delif testbr testif.
backtrace:
[1002130.426411] FS: 00007f2235153700(0000) GS:ffff88007b020000(0000) knlGS:0000000000000000
[1002130.524656] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[1002130.594931] CR2: 0000000000000021 CR3: 0000000001dc7000 CR4: 0000000000002660
[1002130.681798] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[1002130.768654] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[1002130.855525] Process ksoftirqd/1 (pid: 9, threadinfo ffff880062642000, task ffff880062640800)
[1002130.957868] Stack:
[1002130.983758] 0000000080000000 ffff88007bc06a40 ffff88005e3c6c80 ffffffff81901d10
[1002131.073887] ffff88005efc2000 0000000000000001 ffff880062643bf0 ffffffff818497d9
[1002131.163945] ffff88006147e090 0000000000000020 ffff88007bc06a40 ffff88005e3c6c80
[1002131.254023] Call Trace:
[1002131.285086] [<ffffffff81901d10>] ? br_handle_frame_finish+0x2b0/0x2b0
[1002131.364677] [<ffffffff818497d9>] __netif_receive_skb+0x109/0x4a0
[1002131.439081] [<ffffffff81849b12>] __netif_receive_skb+0x442/0x4a0
[1002131.513493] [<ffffffff810e3a6e>] ? __kmalloc_node+0x3e/0x50
[1002131.582744] [<ffffffff8184b7d8>] netif_receive_skb+0x78/0x80
[1002131.653053] [<ffffffff8184b928>] napi_skb_finish+0x48/0x60
[1002131.721269] [<ffffffff8184bf1d>] napi_gro_receive+0xfd/0x130
[1002131.791551] [<ffffffff8192b2f6>] vlan_gro_receive+0x16/0x20
[1002131.860796] [<ffffffff816a41d1>] igb_poll+0x6f1/0xdc0
[1002131.923871] [<ffffffff8196c0d5>] ? __schedule+0x2e5/0x810
[1002131.991071] [<ffffffff8196e38b>] ? _raw_spin_lock_irq+0xb/0x30
[1002132.063421] [<ffffffff8184c0c1>] net_rx_action+0xa1/0x1d0
[1002132.130619] [<ffffffff81057449>] __do_softirq+0x99/0x130
[1002132.196803] [<ffffffff8105759a>] run_ksoftirqd+0xba/0x170
[1002132.264000] [<ffffffff810574e0>] ? __do_softirq+0x130/0x130
[1002132.333258] [<ffffffff8106d306>] kthread+0x96/0xa0
[1002132.393224] [<ffffffff8196ffe4>] kernel_thread_helper+0x4/0x10
[1002132.465580] [<ffffffff8196f0f6>] ? int_ret_from_sys_call+0x7/0x1b
[1002132.541016] [<ffffffff8196e8a1>] ? retint_restore_args+0x5/0x6
[1002132.613368] [<ffffffff8196ffe0>] ? gs_change+0x13/0x13
[1002132.677466] Code: 02 f6 81 a5 01 00 00 40 48 8b 81 e0 02 00 00 89 d6 4c 0f 45 f0 48 8b 05 50 76 20 00 66 33 70 04 66 f7 c6 ff f0 0f 84 d0 00 00 00
[1002132.835500] 0f b6 46 21 3c 02 74 50 3c 03 0f 85 60 ff ff ff 48 8b 05 e1
[1002132.920864] RIP [<ffffffff81901e17>] br_handle_frame+0x107/0x260
[1002132.995296] RSP <ffff880062643b50>
[1002133.038735] CR2: 0000000000000021
Signed-off-by: Xiaoming Gao <newtongao@tencent.com>
---
net/bridge/br_input.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f06ee39..c8b365f 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -122,7 +122,8 @@ static int br_handle_local_finish(struct sk_buff *skb)
{
struct net_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);
return 0; /* process further */
}
@@ -160,6 +161,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
return RX_HANDLER_CONSUMED;
p = br_port_get_rcu(skb->dev);
+ if (!p)
+ goto drop;
if (unlikely(is_link_local(dest))) {
/* Pause frames shouldn't be passed up by driver anyway */
--
1.7.1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-net-bridge-add-null-pointer-check.patch --]
[-- Type: text/plain; charset=gb18030; name="0001-net-bridge-add-null-pointer-check.patch", Size: 4422 bytes --]
From 2b39c4ccd812723891117184b297f6886dcfd976 Mon Sep 17 00:00:00 2001
From: newtongao <newtongao@tencent.com>
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.
method to reproduce null pointer panic:
1. in function del_nbp,amplify the gap between "dev->priv_flags &= ~IFF_BRIDGE_PORT;" and "netdev_rx_handler_unregister(dev);" , such as add new line "while(1);".
2. create net bridge testbr and bind some network interface(e.g. testif) on it.
3. send packets to testif frequetly,such as ping testif.
4. brctl delif testbr testif.
backtrace:
[1002130.426411] FS: 00007f2235153700(0000) GS:ffff88007b020000(0000) knlGS:0000000000000000
[1002130.524656] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[1002130.594931] CR2: 0000000000000021 CR3: 0000000001dc7000 CR4: 0000000000002660
[1002130.681798] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[1002130.768654] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[1002130.855525] Process ksoftirqd/1 (pid: 9, threadinfo ffff880062642000, task ffff880062640800)
[1002130.957868] Stack:
[1002130.983758] 0000000080000000 ffff88007bc06a40 ffff88005e3c6c80 ffffffff81901d10
[1002131.073887] ffff88005efc2000 0000000000000001 ffff880062643bf0 ffffffff818497d9
[1002131.163945] ffff88006147e090 0000000000000020 ffff88007bc06a40 ffff88005e3c6c80
[1002131.254023] Call Trace:
[1002131.285086] [<ffffffff81901d10>] ? br_handle_frame_finish+0x2b0/0x2b0
[1002131.364677] [<ffffffff818497d9>] __netif_receive_skb+0x109/0x4a0
[1002131.439081] [<ffffffff81849b12>] __netif_receive_skb+0x442/0x4a0
[1002131.513493] [<ffffffff810e3a6e>] ? __kmalloc_node+0x3e/0x50
[1002131.582744] [<ffffffff8184b7d8>] netif_receive_skb+0x78/0x80
[1002131.653053] [<ffffffff8184b928>] napi_skb_finish+0x48/0x60
[1002131.721269] [<ffffffff8184bf1d>] napi_gro_receive+0xfd/0x130
[1002131.791551] [<ffffffff8192b2f6>] vlan_gro_receive+0x16/0x20
[1002131.860796] [<ffffffff816a41d1>] igb_poll+0x6f1/0xdc0
[1002131.923871] [<ffffffff8196c0d5>] ? __schedule+0x2e5/0x810
[1002131.991071] [<ffffffff8196e38b>] ? _raw_spin_lock_irq+0xb/0x30
[1002132.063421] [<ffffffff8184c0c1>] net_rx_action+0xa1/0x1d0
[1002132.130619] [<ffffffff81057449>] __do_softirq+0x99/0x130
[1002132.196803] [<ffffffff8105759a>] run_ksoftirqd+0xba/0x170
[1002132.264000] [<ffffffff810574e0>] ? __do_softirq+0x130/0x130
[1002132.333258] [<ffffffff8106d306>] kthread+0x96/0xa0
[1002132.393224] [<ffffffff8196ffe4>] kernel_thread_helper+0x4/0x10
[1002132.465580] [<ffffffff8196f0f6>] ? int_ret_from_sys_call+0x7/0x1b
[1002132.541016] [<ffffffff8196e8a1>] ? retint_restore_args+0x5/0x6
[1002132.613368] [<ffffffff8196ffe0>] ? gs_change+0x13/0x13
[1002132.677466] Code: 02 f6 81 a5 01 00 00 40 48 8b 81 e0 02 00 00 89 d6 4c 0f 45 f0 48 8b 05 50 76 20 00 66 33 70 04 66 f7 c6 ff f0 0f 84 d0 00 00 00
[1002132.835500] 0f b6 46 21 3c 02 74 50 3c 03 0f 85 60 ff ff ff 48 8b 05 e1
[1002132.920864] RIP [<ffffffff81901e17>] br_handle_frame+0x107/0x260
[1002132.995296] RSP <ffff880062643b50>
[1002133.038735] CR2: 0000000000000021
Signed-off-by: Xiaoming Gao <newtongao@tencent.com>
---
net/bridge/br_input.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f06ee39..c8b365f 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -122,7 +122,8 @@ static int br_handle_local_finish(struct sk_buff *skb)
{
struct net_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);
return 0; /* process further */
}
@@ -160,6 +161,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
return RX_HANDLER_CONSUMED;
p = br_port_get_rcu(skb->dev);
+ if (!p)
+ goto drop;
if (unlikely(is_link_local(dest))) {
/* Pause frames shouldn't be passed up by driver anyway */
--
1.7.1
next parent reply other threads:[~2013-06-20 3:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51C2710D.2060405@gmail.com>
2013-06-20 3:08 ` xiaoming gao [this message]
2013-06-20 3:08 ` [PATCH] net bridge: add null pointer check, fix panic xiaoming gao
2013-06-20 4:55 ` [Bridge] " Eric Dumazet
2013-06-20 4:55 ` Eric Dumazet
2013-06-20 4:55 ` Eric Dumazet
[not found] ` <CAHBR9PJQRw2vuSaG6gpUAGVYsrotNVTjYU_YY6jsA6o0mq4-Jw@mail.gmail.com>
2013-06-20 6:53 ` [Bridge] Fwd: " xiaoming gao
2013-06-20 6:53 ` xiaoming gao
2013-06-20 7:00 ` [Bridge] " xiaoming gao
2013-06-20 7:00 ` xiaoming gao
2013-06-20 7:29 ` [Bridge] " Eric Dumazet
2013-06-20 7:29 ` Eric Dumazet
2013-06-20 7:29 ` Eric Dumazet
2013-06-20 7:47 ` [Bridge] " xiaoming gao
2013-06-20 7:47 ` xiaoming gao
2013-06-20 8:14 ` [Bridge] " Eric Dumazet
2013-06-20 8:14 ` Eric Dumazet
2013-06-20 8:14 ` Eric Dumazet
2013-11-11 10:27 ` Alexander Y. Fomichev
2013-11-11 10:27 ` [Bridge] " Alexander Y. Fomichev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C2721B.9050603@gmail.com \
--to=gxm.linux.kernel@gmail.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.