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 <pa...@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 <kevinrich1...@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pa...@netfilter.org>
Signed-off-by: Florian Westphal <f...@strlen.de>
Signed-off-by: Sasha Levin <sas...@kernel.org>
Regards,
Salvatore
