Hi,
On Fri, Sep 06, 2024 at 10:47:04PM +0200, XXX XXX wrote:
> On Fri, 6 Sep 2024 22:04:27 +0200
> Salvatore Bonaccorso <car...@debian.org> wrote:
>
> > Control: tags -1 + moreinfo
> >
> > Hi,
> >
> > On Mon, Sep 02, 2024 at 11:09:42PM +0200, XXX XXX wrote:
> > > Hi,
> > > this bug seems to be fixed in linux kernel 6.1.107,
> > > I suspect the commit that fixed it is:
> > >
> > > commit 6dcc8ba8a6074bb79040f502dc66ad23a58a1c86
> > > Author: Florian Westphal <f...@strlen.de>
> > > Date: Wed Aug 7 21:28:41 2024 +0200
> > >
> > > netfilter: nf_queue: drop packets with cloned unconfirmed conntracks
> > >
> > > [ Upstream commit 7d8dc1c7be8d3509e8f5164dd5df64c8e34d7eeb ]
> > >
> > > Conntrack assumes an unconfirmed entry (not yet committed to global
> > > hash
> > > table) has a refcount of 1 and is not visible to other cores.
> > >
> > > With multicast forwarding this assumption breaks down because such
> > > skbs get cloned after being picked up, i.e. ct->use refcount is > 1.
> > >
> > > Likewise, bridge netfilter will clone broad/mutlicast frames and
> > > all frames in case they need to be flood-forwarded during learning
> > > phase.
> > >
> > > For ip multicast forwarding or plain bridge flood-forward this will
> > > "work" because packets don't leave softirq and are implicitly
> > > serialized.
> > >
> > > With nfqueue this no longer holds true, the packets get queued
> > > and can be reinjected in arbitrary ways.
> > >
> > > Disable this feature, I see no other solution.
> > >
> > > After this patch, nfqueue cannot queue packets except the last
> > > multicast/broadcast packet.
> > >
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Signed-off-by: Florian Westphal <f...@strlen.de>
> > > Signed-off-by: Pablo Neira Ayuso <pa...@netfilter.org>
> > > Signed-off-by: Sasha Levin <sas...@kernel.org>
> >
> > Would you be able to confirm this? In case this is true, then this
> > would imply that the issue should be visible as well current testing
> > until <= 6.10.7-1.
> >
> > Regards,
> > Salvatore
>
> Hi,
>
> for sure it was visible in linux-image-6.10.6+bpo-amd64 that I tried from
> stable backports after the trace popped up again after upgrading to
> linux-image-6.1.0-25-amd64.
> So by checking the changelog for the source file and line shown in the
> traces on kernel.org
> I've spotted this patch that was interesting because I use suricata in
> nfqueue
> mode and because the trace happened always at boot (during the learning
> phase).
> So I first erroneously I tried 6.1.106 and the trace was still there
> and then 6.1.107 and it was gone.
> Hope this helps.
Yes thanks. One option to get a final confirmation and proper closure
tracking, would be if you can cherry-pick the commit on top of the
6.1.106-3 version and see if it resolved the issue.
You could proceed as described in
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
Regards,
Salvatore
