netfilter: drop outermost socket lock in getsockopt()

commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.

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:
Reviewed-by: Xin Long <>

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

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")
Suggested-by: Florian Westphal <>
Signed-off-by: Paolo Abeni <>
Signed-off-by: Pablo Neira Ayuso <>
Tested-by: Krzysztof Piotr Oledzki <>
Signed-off-by: Greg Kroah-Hartman <>

(cherry picked from commit 485595768d89f53581a7527285acf97880fc65a6)

Signed-off-by: Xuewei Zhang <>

Change-Id: I0a90c4020e904375345e0ea6ce991ed2aee44c49
Reviewed-by: Guenter Roeck <>
Reviewed-by: Pradeep Sawlani <>
Commit-Queue: Xuewei Zhang <>
Tested-by: Xuewei Zhang <>
2 files changed