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.
Ciao,
Tito
