CVE-2024-26781: mptcp: fix possible deadlock in subflow diag

In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix possible deadlock in subflow diag

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-sklock-AFINET6){+.+.}-{0:0}, at: tcpdiagputulp net/ipv4/tcpdiag.c:100 [inline] ffff888045870130 (k-sklock-AFINET6){+.+.}-{0:0}, at: tcpdiaggetaux+0x738/0x830 net/ipv4/tcpdiag.c:137

but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spinlock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inetdiagdumpicsk+0x39f/0x1f80 net/ipv4/inetdiag.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}: lockacquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 rawspinlock include/linux/spinlockapismp.h:133 [inline] rawspinlock+0x2e/0x40 kernel/locking/spinlock.c:154 spinlock include/linux/spinlock.h:351 [inline] inethash+0x335/0xbe0 net/ipv4/inethashtables.c:743 inetcsklistenstart+0x23a/0x320 net/ipv4/inetconnectionsock.c:1261 inetlistensk+0x2a2/0x770 net/ipv4/afinet.c:217 inetlisten+0xa3/0x110 net/ipv4/afinet.c:239 rdstcplisteninit+0x3fd/0x5a0 net/rds/tcplisten.c:316 rdstcpinitnet+0x141/0x320 net/rds/tcp.c:577 opsinit+0x352/0x610 net/core/netnamespace.c:136 registerpernetoperations net/core/netnamespace.c:1214 [inline] registerpernetoperations+0x2cb/0x660 net/core/netnamespace.c:1283 registerpernetdevice+0x33/0x80 net/core/netnamespace.c:1370 rdstcpinit+0x62/0xd0 net/rds/tcp.c:735 dooneinitcall+0x238/0x830 init/main.c:1236 doinitcalllevel+0x157/0x210 init/main.c:1298 doinitcalls+0x3f/0x80 init/main.c:1314 kernelinitfreeable+0x42f/0x5d0 init/main.c:1551 kernelinit+0x1d/0x2a0 init/main.c:1441 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1b/0x30 arch/x86/entry/entry64.S:242

-> #0 (k-sklock-AFINET6){+.+.}-{0:0}: checkprevadd kernel/locking/lockdep.c:3134 [inline] checkprevsadd kernel/locking/lockdep.c:3253 [inline] validatechain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 lockacquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lockacquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 locksockfast include/net/sock.h:1723 [inline] subflowgetinfo+0x166/0xd20 net/mptcp/diag.c:28 tcpdiagputulp net/ipv4/tcpdiag.c:100 [inline] tcpdiaggetaux+0x738/0x830 net/ipv4/tcpdiag.c:137 inetskdiagfill+0x10ed/0x1e00 net/ipv4/inetdiag.c:345 inetdiagdumpicsk+0x55b/0x1f80 net/ipv4/inetdiag.c:1061 inetdiagdump+0x211/0x3a0 net/ipv4/inetdiag.c:1263 inetdiagdumpcompat+0x1c1/0x2d0 net/ipv4/inetdiag.c:1371 netlinkdump+0x59b/0xc80 net/netlink/afnetlink.c:2264 netlinkdumpstart+0x5df/0x790 net/netlink/afnetlink.c:2370 netlinkdumpstart include/linux/netlink.h:338 [inline] inetdiagrcvmsgcompat+0x209/0x4c0 net/ipv4/inetdiag.c:1405 sockdiagrcvmsg+0xe7/0x410 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 sockdiagrcv+0x2a/0x40 net/core/sockdiag.c:280 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x221/0x270 net/socket.c:745 syssendmsg+0x525/0x7d0 net/socket.c:2584 syssendmsg net/socket.c:2638 [inline] syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77

As noted by Eric we can break the lock dependency chain avoid dumping ---truncated---