Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack

[Salvatore Bonaccorso <carnil@debian.org>]

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 <fw@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 <fw@strlen.de>
>     Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>     Signed-off-by: Sasha Levin <sashal@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