lkml.org 
[lkml]   [2024]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH AUTOSEL 5.4 6/7] netfilter: conntrack: check SCTP_CID_SHUTDOWN_ACK for vtag setting in sctp_new
    Date
    From: Xin Long <lucien.xin@gmail.com>

    [ Upstream commit 6e348067ee4bc5905e35faa3a8fafa91c9124bc7 ]

    The annotation says in sctp_new(): "If it is a shutdown ack OOTB packet, we
    expect a return shutdown complete, otherwise an ABORT Sec 8.4 (5) and (8)".
    However, it does not check SCTP_CID_SHUTDOWN_ACK before setting vtag[REPLY]
    in the conntrack entry(ct).

    Because of that, if the ct in Router disappears for some reason in [1]
    with the packet sequence like below:

    Client > Server: sctp (1) [INIT] [init tag: 3201533963]
    Server > Client: sctp (1) [INIT ACK] [init tag: 972498433]
    Client > Server: sctp (1) [COOKIE ECHO]
    Server > Client: sctp (1) [COOKIE ACK]
    Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057809]
    Server > Client: sctp (1) [SACK] [cum ack 3075057809]
    Server > Client: sctp (1) [HB REQ]
    (the ct in Router disappears somehow) <-------- [1]
    Client > Server: sctp (1) [HB ACK]
    Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057810]
    Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057810]
    Client > Server: sctp (1) [HB REQ]
    Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057810]
    Client > Server: sctp (1) [HB REQ]
    Client > Server: sctp (1) [ABORT]

    when processing HB ACK packet in Router it calls sctp_new() to initialize
    the new ct with vtag[REPLY] set to HB_ACK packet's vtag.

    Later when sending DATA from Client, all the SACKs from Server will get
    dropped in Router, as the SACK packet's vtag does not match vtag[REPLY]
    in the ct. The worst thing is the vtag in this ct will never get fixed
    by the upcoming packets from Server.

    This patch fixes it by checking SCTP_CID_SHUTDOWN_ACK before setting
    vtag[REPLY] in the ct in sctp_new() as the annotation says. With this
    fix, it will leave vtag[REPLY] in ct to 0 in the case above, and the
    next HB REQ/ACK from Server is able to fix the vtag as its value is 0
    in nf_conntrack_sctp_packet().

    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    ---
    net/netfilter/nf_conntrack_proto_sctp.c | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c
    index e7545bcca805..6b2a215b2786 100644
    --- a/net/netfilter/nf_conntrack_proto_sctp.c
    +++ b/net/netfilter/nf_conntrack_proto_sctp.c
    @@ -299,7 +299,7 @@ sctp_new(struct nf_conn *ct, const struct sk_buff *skb,
    pr_debug("Setting vtag %x for secondary conntrack\n",
    sh->vtag);
    ct->proto.sctp.vtag[IP_CT_DIR_ORIGINAL] = sh->vtag;
    - } else {
    + } else if (sch->type == SCTP_CID_SHUTDOWN_ACK) {
    /* If it is a shutdown ack OOTB packet, we expect a return
    shutdown complete, otherwise an ABORT Sec 8.4 (5) and (8) */
    pr_debug("Setting vtag %x for new conn OOTB\n",
    --
    2.43.0

    \
     
     \ /
      Last update: 2024-05-27 14:53    [W:3.451 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site