Bug#1051592: linux: Regression - upgrade to 6.1.52-1 breaks nftables
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.
Regards,
Salvatore
Reply to: