Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp2798617rdb; Tue, 12 Sep 2023 12:22:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE4cYA+8nJ28cjFo+FCjhYMSIJomIbkLdRQX5SEina0XSVT4JIudAZxDKE3B7Aj4CT0UwrO X-Received: by 2002:aa7:888b:0:b0:68e:3d83:e501 with SMTP id z11-20020aa7888b000000b0068e3d83e501mr862665pfe.13.1694546578534; Tue, 12 Sep 2023 12:22:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694546578; cv=none; d=google.com; s=arc-20160816; b=e9NQYg1qS55NksSKgLWotpcNjrZ7oLdwgl8WxxusLtHsnrA0b8ammkHkr0TUDRilMl YnKO20LJlCckvc8M6o5LWkU45MER2d+DNt4WaZ1r02qtDGQOrum6L8U0joBNzdtR41vQ az8y7k3bIwZ/5KUDc15Fy5zrWM7X17zKbn9wV7k5wPCz4CPiE4YVVeuxj2ygH9nyW7OS ME2ApyrWl5cYfc6A+4xm97KQVeLtKoTCw2FLI/jnjjLN1Vwf5dZUk6iLZfAWbt2XCBog vF6qmdOb9TsCiD8jST9jztDe9zbtjz3Q8HvSp/0WWULDhsgvxb5Ngp50hwXHfPLRhbLS Gkjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:date:message-id:content-transfer-encoding :in-reply-to:mime-version:user-agent:from:cc:references:to:subject :dkim-signature; bh=Ujehp2CrxYPoXuYDlpiKj4du5N6E27baKTbPSJgLyDs=; fh=IW34B2ocGhWDbRMSTKeT+HFdKd5j8suX0r9+pHonupU=; b=audI91U9UotrHy/MqcZDRq0jFueTORYTOtbEWunn5BIzlT2NEwFwk8UmN2BASFHg9t afoK0IaIk27hEFAIW/CFAWf1U3Ekr1PGRLqjqkyB1SUwfyh0k+7wYHwuhbyTM71mKQo9 8owUzSwV48gxBXw+rRsCftGxSD/RS8YWFMfgjacUkrsBc3rTBRtib6aZFjvEGHM143sX byz6mwsDYCni6JOTvdumgQWhS9LyfnSl0DaAXSS1DmSja8GQXflH4Q1Y/5d9qOl6nd/V 2rUxs/MYS8H0JuwBDMtutwN9DPrr1EVtIbXXREveLgiw5FHBHTUdHUhQs7gbiP9hM3Zx ynZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@silentcreek.de header.s=kas202306171005 header.b=I50aEkjT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id d7-20020a656207000000b0056c55eb251csi8246713pgv.123.2023.09.12.12.22.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 12:22:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@silentcreek.de header.s=kas202306171005 header.b=I50aEkjT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id F14658108BCC; Tue, 12 Sep 2023 04:47:52 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.8 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234813AbjILLro (ORCPT + 99 others); Tue, 12 Sep 2023 07:47:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234814AbjILLrg (ORCPT ); Tue, 12 Sep 2023 07:47:36 -0400 Received: from dd20004.kasserver.com (dd20004.kasserver.com [85.13.150.92]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7ED3410D2; Tue, 12 Sep 2023 04:47:31 -0700 (PDT) Received: from dd20004.kasserver.com (dd0804.kasserver.com [85.13.146.35]) by dd20004.kasserver.com (Postfix) with ESMTPSA id EFBC26320998; Tue, 12 Sep 2023 13:47:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=silentcreek.de; s=kas202306171005; t=1694519249; bh=Ujehp2CrxYPoXuYDlpiKj4du5N6E27baKTbPSJgLyDs=; h=Subject:To:References:Cc:From:In-Reply-To:Date:From; b=I50aEkjTO1YDotnc2qFwZ9CM00zhMymhQh3v4UbI4IYSBll47/qoTqM/SeUk6M9kg AbwEoHlZdvCtVcGCL2HQ6KynlRlJOYxepjA24K2qDw86hU3EiJEutMf9BijDSBYI7j R9PLEc9w1P3ROpifpDr/yIIV42BiRzNTNqm8gfqtXzKkiIFAJdNNyZiEtOetb9/xHc SGOJVXn4sN1HuKEk2hGRDjZLOWxHrtnGNCPtFK/m0/deZkrcqdUYcf4TPA5zGQPdmi FjIAP1CW+ypnSQ7De1ONtmJHEZEl37x3gmKkeMn4hYhC0/e70G1X6yGg/EVxJngFLT g1v5SqsU/WWVw== Subject: Re: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable To: regressions@lists.linux.dev, fw@strlen.de References: <20230911213750.5B4B663206F5@dd20004.kasserver.com> <20230912102701.GA13516@breakpoint.cc> Cc: pablo@netfilter.org, kadlec@netfilter.org, fw@strlen.de, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, sashal@kernel.org, carnil@debian.org, 1051592@bugs.debian.org From: "Timo Sigurdsson" User-Agent: ALL-INKL Webmail 2.11 X-SenderIP: 89.246.188.214 MIME-Version: 1.0 In-Reply-To: <20230912102701.GA13516@breakpoint.cc> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-Id: <20230912114729.EFBC26320998@dd20004.kasserver.com> Date: Tue, 12 Sep 2023 13:47:29 +0200 (CEST) X-Spamd-Bar: / Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 12 Sep 2023 04:47:53 -0700 (PDT) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Hi, Florian Westphal schrieb am 12.09.2023 12:27 (GMT +02:00): > Linux regression tracking (Thorsten Leemhuis) > wrote: >> On 12.09.23 00:57, Pablo Neira Ayuso wrote: >> > Userspace nftables v1.0.6 generates incorrect bytecode that hits a new >> > kernel check that rejects adding rules to bound chains. The incorrect >> > bytecode adds the chain binding, attach it to the rule and it adds the >> > rules to the chain binding. I have cherry-picked these three patches >> > for nftables v1.0.6 userspace and your ruleset restores fine. >> > [...] >> >> Hmmmm. Well, this sounds like a kernel regression to me that normally >> should be dealt with on the kernel level, as users after updating the >> kernel should never have to update any userspace stuff to continue what >> they have been doing before the kernel update. > > This is a combo of a userspace bug and this new sanity check that > rejects the incorrect ordering (adding rules to the already-bound > anonymous chain). > Out of curiosity, did the incorrect ordering or bytecode from the older userspace components actually lead to a wrong representation of the rules in the kernel or did the rules still work despite all that? Thanks, Timo