From patchwork Fri Apr 9 14:03:21 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 1464398 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4FH0H31Ch5z9sV5; Sat, 10 Apr 2021 00:03:59 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1lUrjm-0007bB-TP; Fri, 09 Apr 2021 14:03:54 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lUrjZ-0007Px-RZ for kernel-team@lists.ubuntu.com; Fri, 09 Apr 2021 14:03:41 +0000 Received: from mail-pg1-f199.google.com ([209.85.215.199]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lUrjY-0003dE-Vl for kernel-team@lists.ubuntu.com; Fri, 09 Apr 2021 14:03:41 +0000 Received: by mail-pg1-f199.google.com with SMTP id v5so3239143pgj.7 for ; Fri, 09 Apr 2021 07:03:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=a39eFJY05FMOcccYt+UpsOm9xglfaYqRfYIeVDjzjMw=; b=dD3wKlBh2+qL3aOMq+2/sylVufmyNEy+ZzWw3RRWjr3b5YZkHm8RM1WuzA8tX07P/F csHGi4v+r8p7JaEc395u+AsjpS/jCGiP+dyY30qDxjlwGHPWAW93lCZIbh5eiPqzIotH NuOgf/HVh1BdeT1PXpbSUPmh2vuwtdGIJ1bSZbfQrFXMVQjK9v5pVEJ6QTGsUegQnNhQ d1O5XbeUzQ+/Gv9o5r1w/ewaezeVHfMrcqTXVgYrANOJXCUTDBQfMGkjmBpJb3lFmgum 1Qfdjfv6MHJSlv43UuBUXbndQX996WEDdcZJRTpLtJP6UY4rzJKKBM1A1xDynPglid9P Mjug== X-Gm-Message-State: AOAM530hzclNe8GwM28G0YKbRKLT1/VPAj5dO7rArAAxiOts5fH6TtvB sKgk2S6lpFLpCoRmQY5GEcvA0bJ0mPsHNzJG0c79PU2Q3ZV+fj3qERVph6cXMVX+os42L/ixSbL AkXIQzS1S1lJrdinavLn9MfkGKPvjuZSotJLBWd+2Ag== X-Received: by 2002:a17:902:b68c:b029:e6:bb9f:7577 with SMTP id c12-20020a170902b68cb02900e6bb9f7577mr12970940pls.0.1617977019329; Fri, 09 Apr 2021 07:03:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyi21ApAFry5DATgM3AH06AzLlTRviURsWrZke+Ken6EWwsXz9eammf3HzFWx3bKLJ2VMjRNg== X-Received: by 2002:a17:902:b68c:b029:e6:bb9f:7577 with SMTP id c12-20020a170902b68cb02900e6bb9f7577mr12970913pls.0.1617977019115; Fri, 09 Apr 2021 07:03:39 -0700 (PDT) Received: from localhost.localdomain ([69.163.84.166]) by smtp.gmail.com with ESMTPSA id a26sm2584244pff.149.2021.04.09.07.03.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Apr 2021 07:03:38 -0700 (PDT) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH 3/3][F:OEM-5.10] netfilter: x_tables: Use correct memory barriers. Date: Fri, 9 Apr 2021 08:03:21 -0600 Message-Id: <20210409140321.7279-11-tim.gardner@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210409140321.7279-1-tim.gardner@canonical.com> References: <20210409140321.7279-1-tim.gardner@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Mark Tomlinson CVE-2021-29650 When a new table value was assigned, it was followed by a write memory barrier. This ensured that all writes before this point would complete before any writes after this point. However, to determine whether the rules are unused, the sequence counter is read. To ensure that all writes have been done before these reads, a full memory barrier is needed, not just a write memory barrier. The same argument applies when incrementing the counter, before the rules are read. Changing to using smp_mb() instead of smp_wmb() fixes the kernel panic reported in cc00bcaa5899 (which is still present), while still maintaining the same speed of replacing tables. The smb_mb() barriers potentially slow the packet path, however testing has shown no measurable change in performance on a 4-core MIPS64 platform. Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path") Signed-off-by: Mark Tomlinson Signed-off-by: Pablo Neira Ayuso (cherry picked from commit 175e476b8cdf2a4de7432583b49c871345e4f8a1) Signed-off-by: Tim Gardner --- include/linux/netfilter/x_tables.h | 2 +- net/netfilter/x_tables.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h index 5deb099d156d..8ec48466410a 100644 --- a/include/linux/netfilter/x_tables.h +++ b/include/linux/netfilter/x_tables.h @@ -376,7 +376,7 @@ static inline unsigned int xt_write_recseq_begin(void) * since addend is most likely 1 */ __this_cpu_add(xt_recseq.sequence, addend); - smp_wmb(); + smp_mb(); return addend; } diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index 7df3aef39c5c..6bd31a7a27fc 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -1389,7 +1389,7 @@ xt_replace_table(struct xt_table *table, table->private = newinfo; /* make sure all cpus see new ->private value */ - smp_wmb(); + smp_mb(); /* * Even though table entries have now been swapped, other CPU's