From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC72BC07E95 for ; Tue, 13 Jul 2021 10:08:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 98DE9611C0 for ; Tue, 13 Jul 2021 10:08:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235152AbhGMKK7 (ORCPT ); Tue, 13 Jul 2021 06:10:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235109AbhGMKK6 (ORCPT ); Tue, 13 Jul 2021 06:10:58 -0400 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0739EC0613DD for ; Tue, 13 Jul 2021 03:08:09 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id a6so29155329ljq.3 for ; Tue, 13 Jul 2021 03:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=bi6vYY+hQwR2Ckgta+GNAKJVLohlPwz1R/SpzgahLGw=; b=utRMRX6KJOfsKLIKb7zpvzVz5BBZ37t80Qb7dnlIQvIj42mmq3l9xvzoBiXldu+M9u ujTfKfF1AKgg0aBwuGPpO6CW2SC90uiq8/APoAr4FTt+1/7/6pPG9a6GO4DHoqQjNdoA uvWU2xrTdCgX+NkzNDx01AbTQs6IXC2zWUbIx1geEwe4Ysex2IYONI02M0aSKz5bgL+5 TOa1t05tumCfuFkL2KC3qKvXn+T/n/9SFAR+ZnqEuunE1nc5jm7ekVhFoX8trq80ac91 3F9+ijNvkSW0i7Lk4wL0cU7YDm8Z4F+PLwE9N0vgjhpV2T2pUp1dRgxJPMiLosrR+YgW +j1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=bi6vYY+hQwR2Ckgta+GNAKJVLohlPwz1R/SpzgahLGw=; b=f0uCTgQPsBHS4CEPkKRh6dDLi3PnOKZOHNNmszNWLuUvgXdpoTi6EWKBat7gnha9VW J2g+55ucfmC6eirfOUS091xFDcQ5ZT6rnNUSB/jNH6h6OwOmIT/I8rlIlutWkUBHhYX0 ZYoRoIijKF6uc8q5QKJDjzzKHnu40mzXNkPg7Gcq97tzS39Cy2Ul02dxc0RQl8iTsHwc hWoiwaloRn2EIUFOkrMTrzHOtyHVFMnCfoO5b66NoJ7I2ioPwHuKjWTqaU9REHO0eCh+ 3SltbdIEnpgvePEi3EzmaLoVkzYJaG6q+fYYcmEoD8/1zx28EhJr/X7ptLR8Z8a7YpWu OECQ== X-Gm-Message-State: AOAM533hu5dovozWi6fNm5GTD37FxxuX099ScJ98Y8CXfI6DKe9et8PW kUqv4m40bhNixJj4c/fzftardzzmPOLZDYa1Wbco4IFmaW4= X-Google-Smtp-Source: ABdhPJw7NQ30kdc4rkJbO1rP6qEIO9JHWQlseaQgCdwoxBC7CVimOjpwoGMrfaWo2DVJqFRHl+D8lxr4JKdnfalykhU= X-Received: by 2002:a2e:9852:: with SMTP id e18mr3696395ljj.6.1626170886918; Tue, 13 Jul 2021 03:08:06 -0700 (PDT) MIME-Version: 1.0 From: ze wang Date: Tue, 13 Jul 2021 18:07:31 +0800 Message-ID: Subject: [issue] conntrack: lack of lock during nat To: pablo@netfilter.org, netfilter-devel@vger.kernel.org Cc: npl_nad@ucloud.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Hi Pablo, I'm doing CPS testing for conntrack=EF=BC=8Cand I think there may = be an issue in some scenarios. Here is the example=EF=BC=9A iptables -t nat -A POSTROUTING -d 10.0.0.5 -p tcp -j SNAT --to 10.0.0.1 pkt from p1: IP(src=3D"10.0.0.2",dst=3D"10.0.0.5")/TCP(sport=3D5555,dport= =3D8888,seq=3D100) pkt from p2: IP(src=3D"10.0.0.3",dst=3D"10.0.0.5")/TCP(sport=3D5555,dport= =3D8888,seq=3D100) If the number of attempts is large enough, there is a chance that t= he conntracks generated by the two packets will conflict, because their tuples in the reply direction have the same ip and port. The reason for this phenomenon may be in the process of executing nat,there are two small locks in choosing nat tuple(ip and port) and confirming ct, but there is no lock between them(before confirm and after choose), which may cause kernel threads choosing the same reply tuple and confirming them, then go to clash resolve. I=E2=80=99m not sure if my thoughts are correct, or there is any ot= her mechanism in the kernel to prevent this and I didn't find it. Can this be considered an issue? Thank you, wangze