On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote:
> More likely the bug is in fanout_add(), with a buggy sequence in error
> case, and not correct locking.
>
> kfree(po->rollover);
> po->rollover = NULL;
>
> Two cpus entering fanout_add() (using the same af_packet socket,
> syzkaller courtesy...) might both see po->fanout being NULL.
>
> Then they grab the mutex. Too late...
Patch could be :
net/packet/af_packet.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index
d56ee46b11fc9524e457e5fe8adf10c105a66ab6..11725a350f6953d077f754c10e9f52e48924d780
100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1657,7 +1657,6 @@ static int fanout_add(struct sock *sk, u16 id, u16
type_flags)
atomic_long_set(&po->rollover->num_failed, 0);
}
- mutex_lock(&fanout_mutex);
match = NULL;
list_for_each_entry(f, &fanout_list, list) {
if (f->id == id &&
@@ -1704,7 +1703,6 @@ static int fanout_add(struct sock *sk, u16 id, u16
type_flags)
}
}
out:
- mutex_unlock(&fanout_mutex);
if (err) {
kfree(po->rollover);
po->rollover = NULL;
@@ -3698,7 +3696,10 @@ packet_setsockopt(struct socket *sock, int level, int
optname, char __user *optv
if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
- return fanout_add(sk, val & 0xffff, val >> 16);
+ mutex_lock(&fanout_mutex);
+ ret = fanout_add(sk, val & 0xffff, val >> 16);
+ mutex_unlock(&fanout_mutex);
+ return ret;
}
case PACKET_FANOUT_DATA:
{
