Bug#1051592: linux: Regression - upgrade to 6.1.52-1 breaks nftables
Hi,
On Mon, Sep 11, 2023 at 04:28:34PM +0200, Salvatore Bonaccorso wrote:
> Control: found -1 5.10.191-1
>
> On Mon, Sep 11, 2023 at 04:17:46PM +0200, Salvatore Bonaccorso wrote:
> > Control: tags -1 + confirmed upstream
> >
> > Hi,
> >
> > On Mon, Sep 11, 2023 at 04:08:07PM +0200, Salvatore Bonaccorso wrote:
> > > Control: tags -1 - moreinfo unreproducible
> > >
> > > Hi Timo,
> > >
> > > On Mon, Sep 11, 2023 at 03:15:18AM +0200, Timo Sigurdsson wrote:
> > > > Hi,
> > > >
> > > > Salvatore Bonaccorso schrieb am 10.09.2023 12:21 (GMT +02:00):
> > > >
> > > > > Would it be possible to provide a minimal set of rules triggering the
> > > > > issue? Can you reproduce the issue with the official build?
> > > >
> > > > So, I did some more testing on a different machine running the official build. My findings so far are:
> > > > 1) Yes, I can reproduce the issue with the official build.
> > > > 2) The issue depends on the ruleset. The minimal ruleset I have on that machine, doesn't trigger the issue, but when I copy over the ruleset from the machine I first observed this on, then I can reproduce it.
> > > >
> > > > I'm attaching a somewhat stripped down version of my original, rather complex ruleset. It's by no means a "minimal" reproducer, cause I haven't had the time yet to further reduce it in order to see what actually triggers it. But you should be able to observe that this ruleset loads just fine on linux 6.1.38-4, but doesn't anymore on 6.1.52-1.
> > >
> > > Thanks for providing it, this helps debugging the issue.
> > >
> > > > I also started looking into what commit could have introduced this. My first guess "netfilter: nft_dynset: disallow object maps" (23185c6aed1f) is wrong. Even with this one reverted, the issue occurs. I'll try another build with "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) reverted tomorrow evening...
> > >
> > > Thanks, as soon we have the introducing commit we can go to the next
> > > step and check upstream. I cannot trigger the problem with 6.4.13-1 or
> > > 6.5.2.
> >
> > The issue seems to be present already in 6.1.49-rc1, which I had still
> > from local pareparations for the rebases. So the bisection needs to go
> > to the upstream versions between 6.1.38 and 6.1.49 at least.
>
> Additionally the behaviour change is as well in 5.10.191-1 (and
> 5.10.193 upstream), whereeas not triggering in 5.10.179.
>
> So to be on the safe side making the following statement: either this
> is a real regression affecting several stable series or there is an
> intentional upstream change uncovering an issue in ruleset. As the
> behaviour is not in 6.5.2 for now considering it the first case.
Bisected the issue:
$ git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [61fd484b2cf6bc8022e8e5ea6f693a9991740ac2] Linux 6.1.38
git bisect good 61fd484b2cf6bc8022e8e5ea6f693a9991740ac2
# status: waiting for bad commit, 1 good commit known
# bad: [1321ab403b38366a4cfb283145bb2c005becb1e5] Linux 6.1.45
git bisect bad 1321ab403b38366a4cfb283145bb2c005becb1e5
# good: [95d49f79e94d4fa8105c880a266789609f3e791a] ext4: only update i_reserved_data_blocks on successful block allocation
git bisect good 95d49f79e94d4fa8105c880a266789609f3e791a
# good: [f8b61a2c29fc70f64daad698cf09c1f79a0e39f9] drm/amd/display: Set minimum requirement for using PSR-SU on Rembrandt
git bisect good f8b61a2c29fc70f64daad698cf09c1f79a0e39f9
# bad: [bd2decac7345134ea0bd3f4b978478ef53367cd8] mptcp: ensure subflow is unhashed before cleaning the backlog
git bisect bad bd2decac7345134ea0bd3f4b978478ef53367cd8
# bad: [fe3409cd013cfd10d3e6787b49f33a5dda39cffd] RDMA/irdma: Fix op_type reporting in CQEs
git bisect bad fe3409cd013cfd10d3e6787b49f33a5dda39cffd
# good: [85c38ac62c1372cc1ab05426315aad61025d33ef] atheros: fix return value check in atl1_tso()
git bisect good 85c38ac62c1372cc1ab05426315aad61025d33ef
# bad: [539cf23cb48835c69cc3d22edff28b92bd82bb18] tipc: stop tipc crypto on failure in tipc_node_create
git bisect bad 539cf23cb48835c69cc3d22edff28b92bd82bb18
# good: [1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1] x86/traps: Fix load_unaligned_zeropad() handling for shared TDX memory
git bisect good 1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1
# bad: [7218974aba07ff60c646d5a512b02b871402b03e] mm: suppress mm fault logging if fatal signal already pending
git bisect bad 7218974aba07ff60c646d5a512b02b871402b03e
# good: [89a4d1a89751a0fbd520e64091873e19cc0979e8] netfilter: nft_set_rbtree: fix overlap expiration walk
git bisect good 89a4d1a89751a0fbd520e64091873e19cc0979e8
# bad: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
git bisect bad 268cb07ef3ee17b5454a7c4b23376802c5b00c79
# good: [4237462a073e24f71c700f3e5929f07b6ee1bcaa] netfilter: nf_tables: skip immediate deactivate in _PREPARE_ERROR
git bisect good 4237462a073e24f71c700f3e5929f07b6ee1bcaa
# first bad commit: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
$ git bisect visualize
commit 268cb07ef3ee17b5454a7c4b23376802c5b00c79
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Sun Jul 23 16:41:48 2023 +0200
netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
[ Upstream commit 0ebc1064e4874d5987722a2ddbc18f94aa53b211 ]
Bail out with EOPNOTSUPP when adding rule to bound chain via
NFTA_RULE_CHAIN_ID. The following warning splat is shown when
adding a rule to a deleted bound chain:
WARNING: CPU: 2 PID: 13692 at net/netfilter/nf_tables_api.c:2013 nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
CPU: 2 PID: 13692 Comm: chain-bound-rul Not tainted 6.1.39 #1
RIP: 0010:nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
Fixes: d0e2c7de92c7 ("netfilter: nf_tables: add NFT_CHAIN_BINDING")
Reported-by: Kevin Rich <kevinrich1337@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Regards,
Salvatore
Reply to: