--- /dev/null
+From d6a9608af9a75d13243d217f6ce1e30e57d56ffe Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Fri, 23 Feb 2024 17:14:19 +0100
+Subject: mptcp: fix possible deadlock in subflow diag
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+commit d6a9608af9a75d13243d217f6ce1e30e57d56ffe upstream.
+
+Syzbot and Eric reported a lockdep splat in the subflow diag:
+
+ WARNING: possible circular locking dependency detected
+ 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted
+
+ syz-executor.2/24141 is trying to acquire lock:
+ ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:
+ tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]
+ ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:
+ tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137
+
+ but task is already holding lock:
+ ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock
+ include/linux/spinlock.h:351 [inline]
+ ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at:
+ inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038
+
+ which lock already depends on the new lock.
+
+ the existing dependency chain (in reverse order) is:
+
+ -> #1 (&h->lhash2[i].lock){+.+.}-{2:2}:
+ lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
+ __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
+ _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154
+ spin_lock include/linux/spinlock.h:351 [inline]
+ __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743
+ inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261
+ __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217
+ inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239
+ rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316
+ rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577
+ ops_init+0x352/0x610 net/core/net_namespace.c:136
+ __register_pernet_operations net/core/net_namespace.c:1214 [inline]
+ register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283
+ register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370
+ rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735
+ do_one_initcall+0x238/0x830 init/main.c:1236
+ do_initcall_level+0x157/0x210 init/main.c:1298
+ do_initcalls+0x3f/0x80 init/main.c:1314
+ kernel_init_freeable+0x42f/0x5d0 init/main.c:1551
+ kernel_init+0x1d/0x2a0 init/main.c:1441
+ ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
+ ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242
+
+ -> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:
+ check_prev_add kernel/locking/lockdep.c:3134 [inline]
+ check_prevs_add kernel/locking/lockdep.c:3253 [inline]
+ validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869
+ __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137
+ lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
+ lock_sock_fast include/net/sock.h:1723 [inline]
+ subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28
+ tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]
+ tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137
+ inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345
+ inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061
+ __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263
+ inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371
+ netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264
+ __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370
+ netlink_dump_start include/linux/netlink.h:338 [inline]
+ inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405
+ sock_diag_rcv_msg+0xe7/0x410
+ netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
+ sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280
+ netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
+ netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
+ netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
+ sock_sendmsg_nosec net/socket.c:730 [inline]
+ __sock_sendmsg+0x221/0x270 net/socket.c:745
+ ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
+ ___sys_sendmsg net/socket.c:2638 [inline]
+ __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
+ do_syscall_64+0xf9/0x240
+ entry_SYSCALL_64_after_hwframe+0x6f/0x77
+
+As noted by Eric we can break the lock dependency chain avoid
+dumping any extended info for the mptcp subflow listener:
+nothing actually useful is presented there.
+
+Fixes: b8adb69a7d29 ("mptcp: fix lockless access in subflow ULP diag")
+Cc: stable@vger.kernel.org
+Reported-by: Eric Dumazet <edumazet@google.com>
+Closes: https://lore.kernel.org/netdev/CANn89iJ=Oecw6OZDwmSYc9HJKQ_G32uN11L+oUcMu+TOD5Xiaw@mail.gmail.com/
+Suggested-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20240223-upstream-net-20240223-misc-fixes-v1-9-162e87e48497@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/diag.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/mptcp/diag.c
++++ b/net/mptcp/diag.c
+@@ -21,6 +21,9 @@ static int subflow_get_info(struct sock
+ bool slow;
+ int err;
+
++ if (inet_sk_state_load(sk) == TCP_LISTEN)
++ return 0;
++
+ start = nla_nest_start_noflag(skb, INET_ULP_INFO_MPTCP);
+ if (!start)
+ return -EMSGSIZE;