CVE-2024-26781

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-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 —truncated—