Patch "sctp: update transport state when processing a dupcook packet" has been added to the 5.10-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

    sctp: update transport state when processing a dupcook packet

to the 5.10-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:
     sctp-update-transport-state-when-processing-a-dupcoo.patch
and it can be found in the queue-5.10 subdirectory.

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



commit 3954b1d479dbc69207ab2a9cfd4e70ec7c512136
Author: Xin Long <lucien.xin@xxxxxxxxx>
Date:   Sun Oct 1 10:58:45 2023 -0400

    sctp: update transport state when processing a dupcook packet
    
    [ Upstream commit 2222a78075f0c19ca18db53fd6623afb4aff602d ]
    
    During the 4-way handshake, the transport's state is set to ACTIVE in
    sctp_process_init() when processing INIT_ACK chunk on client or
    COOKIE_ECHO chunk on server.
    
    In the collision scenario below:
    
      192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 3922216408]
        192.168.1.1 > 192.168.1.2: sctp (1) [INIT] [init tag: 144230885]
        192.168.1.2 > 192.168.1.1: sctp (1) [INIT ACK] [init tag: 3922216408]
        192.168.1.1 > 192.168.1.2: sctp (1) [COOKIE ECHO]
        192.168.1.2 > 192.168.1.1: sctp (1) [COOKIE ACK]
      192.168.1.1 > 192.168.1.2: sctp (1) [INIT ACK] [init tag: 3914796021]
    
    when processing COOKIE_ECHO on 192.168.1.2, as it's in COOKIE_WAIT state,
    sctp_sf_do_dupcook_b() is called by sctp_sf_do_5_2_4_dupcook() where it
    creates a new association and sets its transport to ACTIVE then updates
    to the old association in sctp_assoc_update().
    
    However, in sctp_assoc_update(), it will skip the transport update if it
    finds a transport with the same ipaddr already existing in the old asoc,
    and this causes the old asoc's transport state not to move to ACTIVE
    after the handshake.
    
    This means if DATA retransmission happens at this moment, it won't be able
    to enter PF state because of the check 'transport->state == SCTP_ACTIVE'
    in sctp_do_8_2_transport_strike().
    
    This patch fixes it by updating the transport in sctp_assoc_update() with
    sctp_assoc_add_peer() where it updates the transport state if there is
    already a transport with the same ipaddr exists in the old asoc.
    
    Signed-off-by: Xin Long <lucien.xin@xxxxxxxxx>
    Reviewed-by: Simon Horman <horms@xxxxxxxxxx>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Link: https://lore.kernel.org/r/fd17356abe49713ded425250cc1ae51e9f5846c6.1696172325.git.lucien.xin@xxxxxxxxx
    Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 2d4ec61877553..765eb617776b3 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -1151,8 +1151,7 @@ int sctp_assoc_update(struct sctp_association *asoc,
 		/* Add any peer addresses from the new association. */
 		list_for_each_entry(trans, &new->peer.transport_addr_list,
 				    transports)
-			if (!sctp_assoc_lookup_paddr(asoc, &trans->ipaddr) &&
-			    !sctp_assoc_add_peer(asoc, &trans->ipaddr,
+			if (!sctp_assoc_add_peer(asoc, &trans->ipaddr,
 						 GFP_ATOMIC, trans->state))
 				return -ENOMEM;
 



[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