Patch "mptcp: never allow the PM to close a listener subflow" has been added to the 5.15-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    mptcp: never allow the PM to close a listener subflow

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     mptcp-never-allow-the-pm-to-close-a-listener-subflow.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 49c896c9c7d30fa84a5e3b4bdfd0620d8164661e
Author: Paolo Abeni <pabeni@xxxxxxxxxx>
Date:   Sat Dec 11 17:11:12 2021 +0100

    mptcp: never allow the PM to close a listener subflow
    
    [ Upstream commit b0cdc5dbcf2ba0d99785da5aabf1b17943805b8a ]
    
    Currently, when deleting an endpoint the netlink PM treverses
    all the local MPTCP sockets, regardless of their status.
    
    If an MPTCP listener socket is bound to the IP matching the
    delete endpoint, the listener TCP socket will be closed.
    That is unexpected, the PM should only affect data subflows.
    
    Additionally, syzbot was able to trigger a NULL ptr dereference
    due to the above:
    
    general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
    CPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897
    Code: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff
    RSP: 0018:ffffc90001f2f818 EFLAGS: 00010016
    RAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000
    RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001
    RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001
    R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000
    R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001
    FS:  00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0
    Call Trace:
     <TASK>
     lock_acquire kernel/locking/lockdep.c:5637 [inline]
     lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602
     __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
     _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162
     finish_wait+0xc0/0x270 kernel/sched/wait.c:400
     inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline]
     inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497
     mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865
     inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739
     mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345
     do_accept+0x382/0x510 net/socket.c:1773
     __sys_accept4_file+0x7e/0xe0 net/socket.c:1816
     __sys_accept4+0xb0/0x100 net/socket.c:1846
     __do_sys_accept net/socket.c:1864 [inline]
     __se_sys_accept net/socket.c:1861 [inline]
     __x64_sys_accept+0x71/0xb0 net/socket.c:1861
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f177cd8b8e9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
    RAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
    RBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c
    R13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000
     </TASK>
    
    Fix the issue explicitly skipping MPTCP socket in TCP_LISTEN
    status.
    
    Reported-and-tested-by: syzbot+e4d843bb96a9431e6331@xxxxxxxxxxxxxxxxxxxxxxxxx
    Reviewed-by: Mat Martineau <mathew.j.martineau@xxxxxxxxxxxxxxx>
    Fixes: 740d798e8767 ("mptcp: remove id 0 address")
    Signed-off-by: Paolo Abeni <pabeni@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/ebc7594cdd420d241fb2172ddb8542ba64717657.1639238695.git.pabeni@xxxxxxxxxx
    Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
index 050eea231528b..b79251a36dcbc 100644
--- a/net/mptcp/pm_netlink.c
+++ b/net/mptcp/pm_netlink.c
@@ -700,6 +700,9 @@ static void mptcp_pm_nl_rm_addr_or_subflow(struct mptcp_sock *msk,
 
 	msk_owned_by_me(msk);
 
+	if (sk->sk_state == TCP_LISTEN)
+		return;
+
 	if (!rm_list->nr)
 		return;
 



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux