Netdev List
 help / color / mirror / Atom feed
From: lvjunyu <lvjunyu@cmss.chinamobile.com>
To: netdev-bot+sashiko@kernel.org
Cc: pablo@netfilter.org, fw@strlen.de, phil@nwl.cc,
	netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	kuba@kernel.org, lvjunyu <lvjunyu@cmss.chinamobile.com>
Subject: Re: [PATCH v2] netfilter: nf_nat: Fix stale outer UDP checksum on VXLAN encapsulated packets
Date: Tue, 22 Sep 2026 14:14:41 +0800	[thread overview]
Message-ID: <20260922061441.752117-1-lvjunyu@cmss.chinamobile.com> (raw)
In-Reply-To: <20260921130312.686493-1-lvjunyu@cmss.chinamobile.com>

On the Sashiko AI review comments:

> [Medium] Peer call-site divergence: after this patch nf_nat's
> __udp_manip_pkt() treats a CHECKSUM_PARTIAL skb whose offload target...

The flowtable software path (nf_flow_nat_ip_udp) is not reached by
the packets this patch fixes. VXLAN outer headers are locally
generated via vxlan_xmit() -> udp_set_csum() and traverse OUTPUT ->
POSTROUTING, where they hit the conntrack NAT path
(__udp_manip_pkt). The flowtable hook (nf_flow_offload_ip_hook)
processes forwarded flows with offloaded conntrack entries; the
VXLAN outer flow uses a random source port (MASQUERADE
--random-fully) and represents a new conntrack entry that has not
yet been offloaded.

The architectural inconsistency is acknowledged: if flowtable
offload of VXLAN tunnel flows is ever introduced, the same LCO
detection would be needed in nf_flow_nat_ip_udp(). The
zero-checksum gate difference (do_csum = !!hdr->check vs.
udph->check || ip_summed == CHECKSUM_PARTIAL) is pre-existing and
unrelated to this patch.

> [Medium] Incomplete/asymmetric fix: the same unguarded
> nf_csum_update() pattern exists at three sibling sites...

The LCO state being fixed is specific to the UDP encapsulation
path: udp_set_csum() LCO branch writes a complete checksum into
uh->check while setting csum_start to the inner transport header.
This split state does not occur for the sibling call sites:

- tcp_manip_pkt(): TCP checksum includes the pseudo-header
  (addresses + ports); the offload target is the TCP header itself
  (csum_start points at the TCP header, not an inner header), so
  the offload-target test would not match.

- icmpv6_manip_pkt(): ICMPv6 checksum includes a pseudo-header;
  the offload target is the ICMPv6 header itself.

- Headers embedded in ICMP errors (via
  nf_nat_icmp_reply_translation): these are byte copies in the
  ICMP payload, not live checksum-offloaded data; ip_summed is
  typically NONE or COMPLETE.

- nf_nat_*_csum_recalc(): handles length field changes in the
  pseudo-header, a different scenario.

Putting the offload-target test in a shared helper (e.g.,
wrapping nf_csum_update()) is architecturally sound and could be
done as a follow-up. This patch is intentionally scoped to the
UDP path where the bug is observed and verified.

> [Low] The new comment states that both the address and the port
> delta are "applying the address and port deltas with the wrong
> sign"...

The reviewer is correct. The two cases are distinct:

- Port delta (pseudohdr=false, PARTIAL): no-op -- neither branch
  in inet_proto_csum_replace4() is taken.

- Address delta (pseudohdr=true, PARTIAL): applied to wrong seed
  -- the else-if(pseudohdr) branch operates on an uncomplemented
  value.

The comment will be reworded to distinguish "not applied at all"
(port) from "applied to the wrong seed" (address) in the next
revision.

pw-bot: cr



  reply	other threads:[~2026-10-08  3:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 13:03 [PATCH v2] netfilter: nf_nat: Fix stale outer UDP checksum on VXLAN encapsulated packets lvjunyu
2026-09-22  6:14 ` lvjunyu [this message]
2026-09-24  7:04 ` netdev-bot+sashiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260922061441.752117-1-lvjunyu@cmss.chinamobile.com \
    --to=lvjunyu@cmss.chinamobile.com \
    --cc=fw@strlen.de \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev-bot+sashiko@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=phil@nwl.cc \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox