Re: [PATCH nf v7 1/1] netfilter: nf_dup: preserve duplication guard across NFQUEUE

[Florian Westphal]

zihan xi <zihanx@xxxxxxxxxx> wrote:
> Hi Florian,
> 
> Thanks again for the review. I tested the simpler approach you suggested:
> extending the local_bh_disable() / local_bh_enable() scope in
> nf_reinject() to cover hook lookup, hook traversal, and okfn execution.
> The experiment changed only nfnetlink_queue.c and built successfully
> against nf.git main at ab699d296e06.
> 
> I ran the IPv6 TEE/NFQUEUE reproducer in a 2-vCPU, 2-GiB QEMU guest
> in a network namespace owned by a non-initial user namespace, with:
> 
> QUEUE_COUNT=1
> PAYLOAD=1
> TEE_CLONES=1
> panic_on_oom=0
> 
> The bounded run reached 68,881 callback iterations in 6.700 seconds and
> exited normally. No OOM, panic, Oops, BUG, or soft lockup was observed.
> This was a bounded resource-consumption run, not an OOM or crash test.
> 
> The reproducer continued executing the callback loop throughout the
> bounded run, so extending the BH-disabled region alone does not address
> this case. It protects against BH interference during nf_reinject(), but
> it does not preserve current->in_nf_duplicate across the asynchronous
> NFQUEUE verdict path: the original ip_local_out() or ip6_local_out()
> call has already returned and cleared the task-local guard before
> reinjection starts.

Why? You'd store the current->in_nf_duplicate struct nf_queue_entry
at queue time ("this skb is due to recursion via nf dup").

Then, on reinject, you'd set current->in_nf_duplicate to the
value stashed in struct nf_queue_entry so that if we were queued earlier
from the recursion a potential further 'dup' would see current->in_nf_duplicate
as true and skip next duplication round.

I think one could add a 'DEBUG_NET_WARN_ONCE(current->in_nf_duplicate)'
in nf_reinject, I don't see how it could be set on function entry.

What did I miss?