* [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
@ 2017-09-14 14:07 nixiaoming
2017-09-14 14:35 ` Willem de Bruijn
0 siblings, 1 reply; 8+ messages in thread
From: nixiaoming @ 2017-09-14 14:07 UTC (permalink / raw)
To: davem, edumazet, waltje, gw4pts, andreyknvl, tklauser,
philip.pettersson, glider, willemdebruijn.kernel
Cc: netdev, linux-kernel, nixiaoming, dede.wu
From: l00219569 <lisimin@huawei.com>
If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
or add spin_lock(&po->bind_lock) before po-> fanout = match
this is a patch for add po->bind_lock in fanout_add
test on linux 4.1.12:
./trinity -c setsockopt -C 2 -X &
BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: G W O 4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[<ffffffc000209414>] dump_backtrace+0x0/0xf8
[<ffffffc00020952c>] show_stack+0x20/0x28
[<ffffffc000635574>] dump_stack+0xac/0xe4
[<ffffffc000633fb8>] panic+0xf8/0x268
[<ffffffc0005fa778>] __unregister_prot_hook+0xa0/0x144
[<ffffffc0005fba48>] packet_set_ring+0x280/0x5b4
[<ffffffc0005fc33c>] packet_setsockopt+0x320/0x950
[<ffffffc000554a04>] SyS_setsockopt+0xa4/0xd4
Signed-off-by: nixiaoming <nixiaoming@huawei.com>
Tested-by: wudesheng <dede.wu@huawei.com>
---
net/packet/af_packet.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 54a18a8..7a52a3b 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1446,12 +1446,16 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
default:
return -EINVAL;
}
-
- if (!po->running)
+ spin_lock(&po->bind_lock);
+ if (!po->running) {
+ spin_unlock(&po->bind_lock);
return -EINVAL;
+ }
- if (po->fanout)
+ if (po->fanout) {
+ spin_unlock(&po->bind_lock);
return -EALREADY;
+ }
mutex_lock(&fanout_mutex);
match = NULL;
@@ -1501,6 +1505,7 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
}
out:
mutex_unlock(&fanout_mutex);
+ spin_unlock(&po->bind_lock);
return err;
}
--
2.10.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
2017-09-14 14:07 [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook nixiaoming
@ 2017-09-14 14:35 ` Willem de Bruijn
2017-09-15 17:41 ` Cong Wang
0 siblings, 1 reply; 8+ messages in thread
From: Willem de Bruijn @ 2017-09-14 14:35 UTC (permalink / raw)
To: nixiaoming
Cc: David Miller, Eric Dumazet, waltje, gw4pts, Andrey Konovalov,
Tobias Klauser, Philip Pettersson, Alexander Potapenko,
Network Development, LKML, dede.wu
On Thu, Sep 14, 2017 at 10:07 AM, nixiaoming <nixiaoming@huawei.com> wrote:
> From: l00219569 <lisimin@huawei.com>
>
> If fanout_add is preempted after running po-> fanout = match
> and before running __fanout_link,
> it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
>
> so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
The packet socket code has no shortage of locks, so there are many
ways to avoid the race condition between fanout_add and packet_set_ring.
Another option would be to lock the socket when calling fanout_add:
- return fanout_add(sk, val & 0xffff, val >> 16);
+ lock_sock(sk);
+ ret = fanout_add(sk, val & 0xffff, val >> 16);
+ release_sock(sk);
+ return ret;
But, for consistency, and to be able to continue to make sense of the
locking policy, we should use the most appropriate lock. This
is po->bind_lock, as it ensures atomicity between testing whether
a protocol hook is active through po->running and the actual existence
of that hook on the protocol hook list.
fanout_mutex protects the fanout object's list. Taking that on
__unregister_prot_hook even in the case where fanout is not
used (and __dev_remove_pack is called) complicates locking
in this already complicated code.
> or add spin_lock(&po->bind_lock) before po-> fanout = match
>
> this is a patch for add po->bind_lock in fanout_add
>
> test on linux 4.1.12:
> ./trinity -c setsockopt -C 2 -X &
Thanks for testing!
>
> BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
> Kernel panic - not syncing: BUG!
> CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: G W O 4.1.12 #1
> Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
> Call trace:
> [<ffffffc000209414>] dump_backtrace+0x0/0xf8
> [<ffffffc00020952c>] show_stack+0x20/0x28
> [<ffffffc000635574>] dump_stack+0xac/0xe4
> [<ffffffc000633fb8>] panic+0xf8/0x268
> [<ffffffc0005fa778>] __unregister_prot_hook+0xa0/0x144
> [<ffffffc0005fba48>] packet_set_ring+0x280/0x5b4
> [<ffffffc0005fc33c>] packet_setsockopt+0x320/0x950
> [<ffffffc000554a04>] SyS_setsockopt+0xa4/0xd4
>
> Signed-off-by: nixiaoming <nixiaoming@huawei.com>
> Tested-by: wudesheng <dede.wu@huawei.com>
> ---
> net/packet/af_packet.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 54a18a8..7a52a3b 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1446,12 +1446,16 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
> default:
> return -EINVAL;
> }
> -
> - if (!po->running)
> + spin_lock(&po->bind_lock);
> + if (!po->running) {
> + spin_unlock(&po->bind_lock);
> return -EINVAL;
> + }
>
> - if (po->fanout)
> + if (po->fanout) {
> + spin_unlock(&po->bind_lock);
> return -EALREADY;
> + }
>
> mutex_lock(&fanout_mutex);
> match = NULL;
> @@ -1501,6 +1505,7 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
> }
> out:
> mutex_unlock(&fanout_mutex);
> + spin_unlock(&po->bind_lock);
This function can call kzalloc with GFP_KERNEL, which may sleep. It is
not correct to sleep while holding a spinlock. Which is why I take the lock
later and test po->running again.
I will clean up that patch and send it for review.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
2017-09-14 14:35 ` Willem de Bruijn
@ 2017-09-15 17:41 ` Cong Wang
2017-09-15 17:46 ` Willem de Bruijn
0 siblings, 1 reply; 8+ messages in thread
From: Cong Wang @ 2017-09-15 17:41 UTC (permalink / raw)
To: Willem de Bruijn
Cc: nixiaoming, David Miller, Eric Dumazet, waltje, gw4pts,
Andrey Konovalov, Tobias Klauser, Philip Pettersson,
Alexander Potapenko, Network Development, LKML, dede.wu
On Thu, Sep 14, 2017 at 7:35 AM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Thu, Sep 14, 2017 at 10:07 AM, nixiaoming <nixiaoming@huawei.com> wrote:
>> From: l00219569 <lisimin@huawei.com>
>>
>> If fanout_add is preempted after running po-> fanout = match
>> and before running __fanout_link,
>> it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
>>
>> so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
>
> The packet socket code has no shortage of locks, so there are many
> ways to avoid the race condition between fanout_add and packet_set_ring.
>
> Another option would be to lock the socket when calling fanout_add:
>
> - return fanout_add(sk, val & 0xffff, val >> 16);
> + lock_sock(sk);
> + ret = fanout_add(sk, val & 0xffff, val >> 16);
> + release_sock(sk);
> + return ret;
>
I don't think this is an option, because __unregister_prot_hook()
can be called without lock_sock(), for example in packet_notifier().
> But, for consistency, and to be able to continue to make sense of the
> locking policy, we should use the most appropriate lock. This
> is po->bind_lock, as it ensures atomicity between testing whether
> a protocol hook is active through po->running and the actual existence
> of that hook on the protocol hook list.
Yeah, register_prot_hook() and unregister_prot_hook() already assume
bind_lock.
[...]
>> out:
>> mutex_unlock(&fanout_mutex);
>> + spin_unlock(&po->bind_lock);
>
> This function can call kzalloc with GFP_KERNEL, which may sleep. It is
> not correct to sleep while holding a spinlock. Which is why I take the lock
> later and test po->running again.
Right, no need to mention the mutex_unlock() before the spin_unlock()
is clearly wrong.
>
> I will clean up that patch and send it for review.
How about the following patch?
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index c26172995511..f5c696a548ed 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1754,10 +1754,14 @@ static int fanout_add(struct sock *sk, u16 id,
u16 type_flags)
match->prot_hook.dev == po->prot_hook.dev) {
err = -ENOSPC;
if (refcount_read(&match->sk_ref) < PACKET_FANOUT_MAX) {
+ spin_lock(&po->bind_lock);
__dev_remove_pack(&po->prot_hook);
- po->fanout = match;
- refcount_set(&match->sk_ref,
refcount_read(&match->sk_ref) + 1);
- __fanout_link(sk, po);
+ if (po->running) {
+ refcount_set(&match->sk_ref,
refcount_read(&match->sk_ref) + 1);
+ po->fanout = match;
+ __fanout_link(sk, po);
+ }
+ spin_unlock(&po->bind_lock);
err = 0;
}
}
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
2017-09-15 17:41 ` Cong Wang
@ 2017-09-15 17:46 ` Willem de Bruijn
2017-09-15 18:09 ` Cong Wang
0 siblings, 1 reply; 8+ messages in thread
From: Willem de Bruijn @ 2017-09-15 17:46 UTC (permalink / raw)
To: Cong Wang
Cc: nixiaoming, David Miller, Eric Dumazet, waltje, gw4pts,
Andrey Konovalov, Tobias Klauser, Philip Pettersson,
Alexander Potapenko, Network Development, LKML, dede.wu
On Fri, Sep 15, 2017 at 1:41 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Sep 14, 2017 at 7:35 AM, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>> On Thu, Sep 14, 2017 at 10:07 AM, nixiaoming <nixiaoming@huawei.com> wrote:
>>> From: l00219569 <lisimin@huawei.com>
>>>
>>> If fanout_add is preempted after running po-> fanout = match
>>> and before running __fanout_link,
>>> it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
>>>
>>> so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
>>
>> The packet socket code has no shortage of locks, so there are many
>> ways to avoid the race condition between fanout_add and packet_set_ring.
>>
>> Another option would be to lock the socket when calling fanout_add:
>>
>> - return fanout_add(sk, val & 0xffff, val >> 16);
>> + lock_sock(sk);
>> + ret = fanout_add(sk, val & 0xffff, val >> 16);
>> + release_sock(sk);
>> + return ret;
>>
>
> I don't think this is an option, because __unregister_prot_hook()
> can be called without lock_sock(), for example in packet_notifier().
>
>
>> But, for consistency, and to be able to continue to make sense of the
>> locking policy, we should use the most appropriate lock. This
>> is po->bind_lock, as it ensures atomicity between testing whether
>> a protocol hook is active through po->running and the actual existence
>> of that hook on the protocol hook list.
>
> Yeah, register_prot_hook() and unregister_prot_hook() already assume
> bind_lock.
>
> [...]
>
>>> out:
>>> mutex_unlock(&fanout_mutex);
>>> + spin_unlock(&po->bind_lock);
>>
>> This function can call kzalloc with GFP_KERNEL, which may sleep. It is
>> not correct to sleep while holding a spinlock. Which is why I take the lock
>> later and test po->running again.
>
>
> Right, no need to mention the mutex_unlock() before the spin_unlock()
> is clearly wrong.
>
>
>>
>> I will clean up that patch and send it for review.
>
> How about the following patch?
>
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index c26172995511..f5c696a548ed 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1754,10 +1754,14 @@ static int fanout_add(struct sock *sk, u16 id,
> u16 type_flags)
> match->prot_hook.dev == po->prot_hook.dev) {
> err = -ENOSPC;
> if (refcount_read(&match->sk_ref) < PACKET_FANOUT_MAX) {
> + spin_lock(&po->bind_lock);
> __dev_remove_pack(&po->prot_hook);
> - po->fanout = match;
> - refcount_set(&match->sk_ref,
> refcount_read(&match->sk_ref) + 1);
> - __fanout_link(sk, po);
> + if (po->running) {
> + refcount_set(&match->sk_ref,
> refcount_read(&match->sk_ref) + 1);
> + po->fanout = match;
> + __fanout_link(sk, po);
> + }
> + spin_unlock(&po->bind_lock);
> err = 0;
> }
> }
In case of failure we also need to unlink and free match. I
sent the following:
http://patchwork.ozlabs.org/patch/813945/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
2017-09-15 17:46 ` Willem de Bruijn
@ 2017-09-15 18:09 ` Cong Wang
0 siblings, 0 replies; 8+ messages in thread
From: Cong Wang @ 2017-09-15 18:09 UTC (permalink / raw)
To: Willem de Bruijn
Cc: nixiaoming, David Miller, Eric Dumazet, waltje, gw4pts,
Andrey Konovalov, Tobias Klauser, Philip Pettersson,
Alexander Potapenko, Network Development, LKML, dede.wu
On Fri, Sep 15, 2017 at 10:46 AM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> In case of failure we also need to unlink and free match. I
> sent the following:
>
> http://patchwork.ozlabs.org/patch/813945/
Ah, will take a look.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
@ 2017-09-14 2:44 nixiaoming
0 siblings, 0 replies; 8+ messages in thread
From: nixiaoming @ 2017-09-14 2:44 UTC (permalink / raw)
To: davem, edumazet, waltje, gw4pts, andreyknvl, tklauser,
philip.pettersson, glider
Cc: netdev, linux-kernel, nixiaoming, dede.wu
If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
or add spin_lock(&po->bind_lock) before po-> fanout = match
test on linux 4.1.12:
./trinity -c setsockopt -C 2 -X &
BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: G W O 4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[<ffffffc000209414>] dump_backtrace+0x0/0xf8
[<ffffffc00020952c>] show_stack+0x20/0x28
[<ffffffc000635574>] dump_stack+0xac/0xe4
[<ffffffc000633fb8>] panic+0xf8/0x268
[<ffffffc0005fa778>] __unregister_prot_hook+0xa0/0x144
[<ffffffc0005fba48>] packet_set_ring+0x280/0x5b4
[<ffffffc0005fc33c>] packet_setsockopt+0x320/0x950
[<ffffffc000554a04>] SyS_setsockopt+0xa4/0xd4
Signed-off-by: nixiaoming <nixiaoming@huawei.com>
Tested-by: wudesheng <dede.wu@huawei.com>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 008a45c..0300146 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool sync)
po->running = 0;
+ mutex_lock(&fanout_mutex);
if (po->fanout)
__fanout_unlink(sk, po);
else
__dev_remove_pack(&po->prot_hook);
+ mutex_unlock(&fanout_mutex);
__sock_put(sk);
--
2.11.0.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
@ 2017-09-14 2:40 nixiaoming
2017-09-14 11:22 ` Willem de Bruijn
0 siblings, 1 reply; 8+ messages in thread
From: nixiaoming @ 2017-09-14 2:40 UTC (permalink / raw)
To: davem, edumazet, waltje, gw4pts, andreyknvl, tklauser,
philip.pettersson, glider
Cc: netdev, linux-kernel, nixiaoming, dede.wu
If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
or add spin_lock(&po->bind_lock) before po-> fanout = match
test on linux 4.1.42:
./trinity -c setsockopt -C 2 -X &
BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: G W O 4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[<ffffffc000209414>] dump_backtrace+0x0/0xf8
[<ffffffc00020952c>] show_stack+0x20/0x28
[<ffffffc000635574>] dump_stack+0xac/0xe4
[<ffffffc000633fb8>] panic+0xf8/0x268
[<ffffffc0005fa778>] __unregister_prot_hook+0xa0/0x144
[<ffffffc0005fba48>] packet_set_ring+0x280/0x5b4
[<ffffffc0005fc33c>] packet_setsockopt+0x320/0x950
[<ffffffc000554a04>] SyS_setsockopt+0xa4/0xd4
Signed-off-by: nixiaoming <nixiaoming@huawei.com>
Tested-by: wudesheng <dede.wu@huawei.com>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 008a45c..0300146 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool sync)
po->running = 0;
+ mutex_lock(&fanout_mutex);
if (po->fanout)
__fanout_unlink(sk, po);
else
__dev_remove_pack(&po->prot_hook);
+ mutex_unlock(&fanout_mutex);
__sock_put(sk);
--
2.11.0.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
2017-09-14 2:40 nixiaoming
@ 2017-09-14 11:22 ` Willem de Bruijn
0 siblings, 0 replies; 8+ messages in thread
From: Willem de Bruijn @ 2017-09-14 11:22 UTC (permalink / raw)
To: nixiaoming
Cc: David Miller, Eric Dumazet, waltje, gw4pts, Andrey Konovalov,
Tobias Klauser, philip.pettersson, Alexander Potapenko,
Network Development, LKML, dede.wu
On Wed, Sep 13, 2017 at 10:40 PM, nixiaoming <nixiaoming@huawei.com> wrote:
> If fanout_add is preempted after running po-> fanout = match
> and before running __fanout_link,
> it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
>
> so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
> or add spin_lock(&po->bind_lock) before po-> fanout = match
>
> test on linux 4.1.42:
> ./trinity -c setsockopt -C 2 -X &
>
> BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
> Kernel panic - not syncing: BUG!
> CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: G W O 4.1.12 #1
> Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
> Call trace:
> [<ffffffc000209414>] dump_backtrace+0x0/0xf8
> [<ffffffc00020952c>] show_stack+0x20/0x28
> [<ffffffc000635574>] dump_stack+0xac/0xe4
> [<ffffffc000633fb8>] panic+0xf8/0x268
> [<ffffffc0005fa778>] __unregister_prot_hook+0xa0/0x144
> [<ffffffc0005fba48>] packet_set_ring+0x280/0x5b4
> [<ffffffc0005fc33c>] packet_setsockopt+0x320/0x950
> [<ffffffc000554a04>] SyS_setsockopt+0xa4/0xd4
>
> Signed-off-by: nixiaoming <nixiaoming@huawei.com>
> Tested-by: wudesheng <dede.wu@huawei.com>
> ---
> net/packet/af_packet.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 008a45c..0300146 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool sync)
>
> po->running = 0;
>
> + mutex_lock(&fanout_mutex);
> if (po->fanout)
> __fanout_unlink(sk, po);
> else
> __dev_remove_pack(&po->prot_hook);
> + mutex_unlock(&fanout_mutex);
>
> __sock_put(sk);
I happened to be looking at the same or a very similar race, courtesy
of syzkaller. packet_set_ring and fanout_add can race.
I believe that one bug is in fanout_add removing the socket
protocol hook and adding the fanout protocol hook without holding
po->bind_lock.
That lock ensures atomic updates to po->running and the actual
protocol hook. fanout_add tests po->running without holding the lock
if (!po->running)
goto out;
and later unconditionally unbinds the socket protocol hook and binds
the fanout group protocol hook:
if (refcount_read(&match->sk_ref) < PACKET_FANOUT_MAX) {
__dev_remove_pack(&po->prot_hook);
po->fanout = match;
refcount_set(&match->sk_ref,
refcount_read(&match->sk_ref) + 1);
__fanout_link(sk, po);
err = 0;
}
This can happen after packet_set_ring has already removed the
protocol hook, causing the socket to be added to the fanout list
twice.
Testing po->running again, this time while holding the bind_lock,
ensures that packet_set_ring cannot have dropped it in between:
+ spin_lock(&po->bind_lock);
+ if (!po->running) {
+ net_err_ratelimited("fanout add, but
unbound sock");
+ err = -EFAULT;
+ spin_unlock(&po->bind_lock);
+ goto out;
+ }
+ __dev_remove_pack(&po->prot_hook));
po->fanout = match;
refcount_set(&match->sk_ref,
refcount_read(&match->sk_ref) + 1);
__fanout_link(sk, po);
+ spin_unlock(&po->bind_lock);
I verified that the reproducer logs plenty of "fanout add, but unbound
sock" messages.
I intend to send this fix after cleaning it up a bit. Will take a
closer look at your patch to see whether these are indeed the
same bug report.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-09-15 18:09 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-14 14:07 [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook nixiaoming
2017-09-14 14:35 ` Willem de Bruijn
2017-09-15 17:41 ` Cong Wang
2017-09-15 17:46 ` Willem de Bruijn
2017-09-15 18:09 ` Cong Wang
-- strict thread matches above, loose matches on Subject: below --
2017-09-14 2:44 nixiaoming
2017-09-14 2:40 nixiaoming
2017-09-14 11:22 ` Willem de Bruijn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).