All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net v2] netfilter: drop outermost socket lock in getsockopt()
@ 2018-02-08 11:19 Paolo Abeni
  2018-02-08 11:48 ` Xin Long
  2018-02-14 19:44 ` Pablo Neira Ayuso
  0 siblings, 2 replies; 3+ messages in thread
From: Paolo Abeni @ 2018-02-08 11:19 UTC (permalink / raw)
  To: netdev; +Cc: David S. Miller, Florian Westphal, Xin Long, netfilter-devel

The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:

======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
  (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74

but task is already holding lock:
  (&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041

which lock already depends on the new lock.
===

Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.

v1 -> v2: fix bad subj, added relavant 'fixes' tag

Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d@syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 net/ipv4/ip_sockglue.c   |  7 +------
 net/ipv6/ipv6_sockglue.c | 10 ++--------
 2 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 008be04ac1cc..9c41a0cef1a5 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1567,10 +1567,7 @@ int ip_getsockopt(struct sock *sk, int level,
 		if (get_user(len, optlen))
 			return -EFAULT;
 
-		lock_sock(sk);
-		err = nf_getsockopt(sk, PF_INET, optname, optval,
-				&len);
-		release_sock(sk);
+		err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
 		if (err >= 0)
 			err = put_user(len, optlen);
 		return err;
@@ -1602,9 +1599,7 @@ int compat_ip_getsockopt(struct sock *sk, int level, int optname,
 		if (get_user(len, optlen))
 			return -EFAULT;
 
-		lock_sock(sk);
 		err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
-		release_sock(sk);
 		if (err >= 0)
 			err = put_user(len, optlen);
 		return err;
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index d78d41fc4b1a..24535169663d 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1367,10 +1367,7 @@ int ipv6_getsockopt(struct sock *sk, int level, int optname,
 		if (get_user(len, optlen))
 			return -EFAULT;
 
-		lock_sock(sk);
-		err = nf_getsockopt(sk, PF_INET6, optname, optval,
-				&len);
-		release_sock(sk);
+		err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
 		if (err >= 0)
 			err = put_user(len, optlen);
 	}
@@ -1409,10 +1406,7 @@ int compat_ipv6_getsockopt(struct sock *sk, int level, int optname,
 		if (get_user(len, optlen))
 			return -EFAULT;
 
-		lock_sock(sk);
-		err = compat_nf_getsockopt(sk, PF_INET6,
-					   optname, optval, &len);
-		release_sock(sk);
+		err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
 		if (err >= 0)
 			err = put_user(len, optlen);
 	}
-- 
2.14.3


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH net v2] netfilter: drop outermost socket lock in getsockopt()
  2018-02-08 11:19 [PATCH net v2] netfilter: drop outermost socket lock in getsockopt() Paolo Abeni
@ 2018-02-08 11:48 ` Xin Long
  2018-02-14 19:44 ` Pablo Neira Ayuso
  1 sibling, 0 replies; 3+ messages in thread
From: Xin Long @ 2018-02-08 11:48 UTC (permalink / raw)
  To: Paolo Abeni
  Cc: network dev, David S. Miller, Florian Westphal, netfilter-devel

On Thu, Feb 8, 2018 at 7:19 PM, Paolo Abeni <pabeni@redhat.com> wrote:
> The Syzbot reported a possible deadlock in the netfilter area caused by
> rtnl lock, xt lock and socket lock being acquired with a different order
> on different code paths, leading to the following backtrace:
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 4.15.0+ #301 Not tainted
> ------------------------------------------------------
> syzkaller233489/4179 is trying to acquire lock:
>   (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
>
> but task is already holding lock:
>   (&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
> xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
>
> which lock already depends on the new lock.
> ===
>
> Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
> only in the required scope"), we already acquire the socket lock in
> the innermost scope, where needed. In such commit I forgot to remove
> the outer-most socket lock from the getsockopt() path, this commit
> addresses the issues dropping it now.
>
> v1 -> v2: fix bad subj, added relavant 'fixes' tag
>
> Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
> Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
> Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
> Reported-by: syzbot+ddde1c7b7ff7442d7f2d@syzkaller.appspotmail.com
> Suggested-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
>  net/ipv4/ip_sockglue.c   |  7 +------
>  net/ipv6/ipv6_sockglue.c | 10 ++--------
>  2 files changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index 008be04ac1cc..9c41a0cef1a5 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -1567,10 +1567,7 @@ int ip_getsockopt(struct sock *sk, int level,
>                 if (get_user(len, optlen))
>                         return -EFAULT;
>
> -               lock_sock(sk);
> -               err = nf_getsockopt(sk, PF_INET, optname, optval,
> -                               &len);
> -               release_sock(sk);
> +               err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
>                 if (err >= 0)
>                         err = put_user(len, optlen);
>                 return err;
> @@ -1602,9 +1599,7 @@ int compat_ip_getsockopt(struct sock *sk, int level, int optname,
>                 if (get_user(len, optlen))
>                         return -EFAULT;
>
> -               lock_sock(sk);
>                 err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
> -               release_sock(sk);
>                 if (err >= 0)
>                         err = put_user(len, optlen);
>                 return err;
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index d78d41fc4b1a..24535169663d 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -1367,10 +1367,7 @@ int ipv6_getsockopt(struct sock *sk, int level, int optname,
>                 if (get_user(len, optlen))
>                         return -EFAULT;
>
> -               lock_sock(sk);
> -               err = nf_getsockopt(sk, PF_INET6, optname, optval,
> -                               &len);
> -               release_sock(sk);
> +               err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
>                 if (err >= 0)
>                         err = put_user(len, optlen);
>         }
> @@ -1409,10 +1406,7 @@ int compat_ipv6_getsockopt(struct sock *sk, int level, int optname,
>                 if (get_user(len, optlen))
>                         return -EFAULT;
>
> -               lock_sock(sk);
> -               err = compat_nf_getsockopt(sk, PF_INET6,
> -                                          optname, optval, &len);
> -               release_sock(sk);
> +               err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
>                 if (err >= 0)
>                         err = put_user(len, optlen);
>         }
> --
> 2.14.3
>
Reviewed-by: Xin Long <lucien.xin@gmail.com>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH net v2] netfilter: drop outermost socket lock in getsockopt()
  2018-02-08 11:19 [PATCH net v2] netfilter: drop outermost socket lock in getsockopt() Paolo Abeni
  2018-02-08 11:48 ` Xin Long
@ 2018-02-14 19:44 ` Pablo Neira Ayuso
  1 sibling, 0 replies; 3+ messages in thread
From: Pablo Neira Ayuso @ 2018-02-14 19:44 UTC (permalink / raw)
  To: Paolo Abeni
  Cc: netdev, David S. Miller, Florian Westphal, Xin Long, netfilter-devel

On Thu, Feb 08, 2018 at 12:19:00PM +0100, Paolo Abeni wrote:
> The Syzbot reported a possible deadlock in the netfilter area caused by
> rtnl lock, xt lock and socket lock being acquired with a different order
> on different code paths, leading to the following backtrace:
> 
> ======================================================
> WARNING: possible circular locking dependency detected
> 4.15.0+ #301 Not tainted
> ------------------------------------------------------
> syzkaller233489/4179 is trying to acquire lock:
>   (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 
> but task is already holding lock:
>   (&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
> xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
> 
> which lock already depends on the new lock.
> ===
> 
> Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
> only in the required scope"), we already acquire the socket lock in
> the innermost scope, where needed. In such commit I forgot to remove
> the outer-most socket lock from the getsockopt() path, this commit
> addresses the issues dropping it now.

Applied, thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-02-14 19:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-08 11:19 [PATCH net v2] netfilter: drop outermost socket lock in getsockopt() Paolo Abeni
2018-02-08 11:48 ` Xin Long
2018-02-14 19:44 ` Pablo Neira Ayuso

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.