Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] netfilter: nf_queue synchronous bypass triggers false DEBUG_NET_WARN_ONCE --
commit 6ab1ebe7cd71aef0c99fc87d28ca2657ffc20779 Author: Zihan Xi <[email protected]> netfilter: nf_dup: preserve guard across NFQUEUE reinjection This commit saves the task-local in_nf_duplicate guard into struct nf_queue_entry when queuing a packet and restores it during reinjection. It also adds a warning in nf_reinject() to ensure it is not called with the guard already set. > diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c > index 477fc632657f4..1ec9c1fbae843 100644 > --- a/net/netfilter/nfnetlink_queue.c > +++ b/net/netfilter/nfnetlink_queue.c [ ... ] > @@ -369,17 +370,24 @@ static void nf_reinject(struct nf_queue_entry *entry, > unsigned int verdict) > unsigned int i; > int err; > u8 pf; > + bool old_in_nf_duplicate; > + > + DEBUG_NET_WARN_ONCE(current->in_nf_duplicate, > + "%s called with duplication guard set", __func__); [Severity: High] Does this warning falsely trigger when a packet is synchronously reinjected during queue bypass? When an NFQUEUE rule is configured with queue-bypass (fail-open), packets are synchronously reinjected if the netlink queue is full. This synchronous reinjection path (nfqnl_enqueue_packet() -> nfqnl_reinject() -> nf_reinject()) executes in the same task context as the original hook traversal. If the packet was originally duplicated via xt_TEE or nft_dup, current->in_nf_duplicate will already be true. Because this can be triggered by remote traffic intentionally filling a bypass-enabled queue with duplicated packets, could this introduce a remotely triggerable regression on systems with panic_on_warn enabled? > + local_bh_disable(); > + old_in_nf_duplicate = current->in_nf_duplicate; > > net = entry->state.net; > pf = entry->state.pf; -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
