From: Xin Long <lucien.xin@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: network dev <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Florian Westphal <fw@strlen.de>,
netfilter-devel@vger.kernel.org
Subject: Re: [PATCH net] netfilter: on setsockopt() acquire sock lock only in the required scope
Date: Thu, 8 Feb 2018 19:04:45 +0800 [thread overview]
Message-ID: <CADvbK_cRXP4NRjQYAQYS6CwRf7z+aRkFP8_df6ZF+SutukCVnQ@mail.gmail.com> (raw)
In-Reply-To: <0faf65d7a9b102fbe107d1bb75b5d97e4622ee3e.1518084409.git.pabeni@redhat.com>
On Thu, Feb 8, 2018 at 6:38 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.
>
> 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
>
Patch looks good to me, the better way to fix this deadlock,
just the subject should be 'getsockopt' instead.
Thanks.
prev parent reply other threads:[~2018-02-08 11:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 10:38 [PATCH net] netfilter: on setsockopt() acquire sock lock only in the required scope Paolo Abeni
2018-02-08 11:04 ` Xin Long [this message]
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=CADvbK_cRXP4NRjQYAQYS6CwRf7z+aRkFP8_df6ZF+SutukCVnQ@mail.gmail.com \
--to=lucien.xin@gmail.com \
--cc=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
/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 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).