Linux Kernel Fix CVE-2025-68206: seqadj for FTP NAT in nftables Conntrack

The Linux kernel received a targeted fix that addresses a subtle but disruptive netfilter edge case: CVE-2025-68206 adds a seqadj extension inside nftables’ conntrack helper path so NAT’ed FTP control connections (PASV/EPSV) are correctly sequence-adjusted when payload bytes are rewritten — a change that prevents broken FTP sessions, kernel WARN logs and connection failures in NAT scenarios.

Background / Overview​

Netfilter, conntrack and nftables form the packet inspection and connection-tracking backbone for modern Linux networking stacks. Tools like nftables (nft) rely on conntrack helpers to understand application-level control channels — FTP is the canonical example — so the kernel can rewrite IP/port values embedded inside control-channel payloads and keep the data and networking stacks coherent.
FTP’s PASV/EPSV modes are particularly thorny: the server sends the client an IPort tuple in the control stream, the NAT device rewrites that tuple, and the kernel must also adjust TCP sequence/acknowledgement expectations to reflect the added/removed payload bytes. If the kernel does not attach a “sequence adjustment” object to the conntrack state at the right time, the client and server can desynchronize, triggering retransmits, server-side closes, or persistent broken connections.
CVE-2025-68206 is a small, surgical upstream fix that ensures nft_ct (the nftables conntrack helper glue) sets up the sequence‑adjustment extension when a conntrack helper is assigned to a connection that already has a NAT binding. The National Vulnerability Database entry documents the problem and reproduction details.

---

What went wrong: technical anatomy​

The reproduction pattern​

The bug surfaces when a conntrack helper (for example, the FTP helper) is associated with an existing connection that already has a NAT mapping — in short, helper assigned after NAT. The NVD description and upstream discussion use an example nft ruleset that models the condition: an inet table assigns the ftp helper while a separate ip nat table already contains DNAT/SNAT rules. Under this ordering, the kernel previously failed to add the seqadj extension at the point where it was needed; the control-channel payload gets altered without the corresponding tracking of sequence deltas. The symptom is practical and observable:

• The FTP client may receive an error (for example, the server closes the control connection after a PASV response).
• Kernel logs show a warning trace indicating the missing seqadj setup and related netfilter/nf_nat code paths.
• The underlying cause is not arbitrary memory corruption but missing sequence adjustment bookkeeping that the rest of the conntrack + NAT machinery expects.

This concrete reproduction and log snippets are recorded in public vulnerability trackers and in the patch discussion threads.

Why seqadj matters for FTP PASV/EPSV​

FTP PASV/EPSV replies contain textual tuples such as “Entering passive mode (192,168,100,1,209,129)”. When NAT rewrites those bytes, the payload length and byte offsets change. TCP is a byte-stream protocol; conntrack/NAT must tell customers (the TCP stack and retransmit logic) that the payload observed at the other side has been modified so sequence numbers and retransmit windows remain consistent.
The kernel uses a sequence adjustment extension (seqadj) in conntrack to track per-connection deltas that arise from payload rewriting. If seqadj is absent (or set up too late), packets will be processed without correcting for the rewritten bytes, producing retransmit storms or protocol-level failures on the application channel. The fix for CVE-2025-68206 ensures nft_ct sets up this extension when a NAT pairing and helper assignment combine in the problematic order. Evidence of this design and the rationale is documented in upstream patches and patch discussion threads.

---

The upstream fix and patch discussion​

What the patch does​

Upstream maintainers accepted a concise change that adds a helper function and ensures the seqadj extension is created when nftables assigns a conntrack helper on a connection that already carries a NAT binding. The patch series author (Andrii Melnychenko) explained the rationale and provided reproducible test scenarios; those patch threads and the patchew mirror show both the code intent and the review conversation that refined the approach. One suggested followup in discussion was to adjust verdict handling (forcing a retransmit in some paths) to avoid leaving stale, nonfunctional connections. The key technical action is: during nft_ct helper assignment, call nfct_seqadj_ext_add (or equivalent) to provision the sequence-adjustment extension when the conntrack entry has a nat binding that will cause payload rewriting.

Patch review highlights and nuance​

• Reviewers discussed DNAT vs SNAT ordering and boundary cases where the NAT may be applied later in the processing path. The accepted fix addresses the missed extension creation scenario; other ordering cases were carefully considered to avoid redundant or unsafe extension manipulation.
• The patch author and reviewers favored a defensive approach: create seqadj when required rather than redesigning the helper/NAT ordering semantics. This keeps the change small, backportable and low risk for stable kernel branches.
• The mailing-list discussion noted one practical test change: force a retransmit in certain verdict paths so stuck connections are retried cleanly rather than left in a half-broken state. That nuance reflects hard-earned experience with subtle control-channel timing differences in real networks.

---

Impact, exploitability and who should care​

Primary impact: reliability and availability​

This vulnerability's observed impact is operational: broken or failing FTP sessions in NAT environments. It is not described in public advisories as granting remote code execution or privilege escalation. Instead, the problem is a correctness/availability defect: clients get disconnected, servers close sessions, and forward-layer systems may log WARN messages. Both the NVD entry and third-party trackers classify the issue as a functional bug that can produce service disruption in the affected scenarios.

Attack vector and privileges required​

• Attack vector: local/operational — the bug manifests when someone can install or alter nft rules that assign helpers and create NAT bindings in the vulnerable ordering. In many production systems, such operations require administrative or orchestration privileges.
• Practical exposure: high for network boxes, routers, cloud NAT gateways, appliance images, and multi‑tenant hosts that allow delegated rule installation; low for isolated single-host desktops where users cannot manipulate conntrack/nft state.

Nessus/Tenable and other scanning plugins already map the CVE to distribution kernel packages or mark certain packages unpatched until backports are available; that indicates the issue has been triaged and vendors will (or have) released backports for supported kernel branches.

Real-world scenarios to prioritize​

• Edge NAT appliances doing FTP application rewriting (traditional FTP proxies and older appliance workflows).
• Cloud NAT gateways or virtual routers that forward FTP control channels and expose helper/CT configuration.
• Multi‑tenant hypervisors or router VMs where untrusted tenants might be able to manipulate netfilter/nft rules.

If your estate runs FTP-aware NATs, virtual routers, or network appliances based on Linux kernels with nftables conntrack helpers, prioritize validation and patching accordingly.

---

Detection and operational hunting​

This class of bug leaves both overt and subtle signals. Focus your hunt on:

• Kernel logs: dmesg and journalctl -k for messages mentioning nf_conntrack_seqadj, nf_nat_ftp, nf_nat_mangle_tcp_packet, or “Missing nfct_seqadj_ext_add setup call” — public examples include the exact trace fragments seen when the condition occurs.
• Application symptoms: FTP clients repeatedly failing after PASV responses, server-side CONNECTION CLOSED messages (421 Service not available or similar) immediately after passive-mode replies.
• Rule-change telemetry: audit logs or orchestration events that install or reorder nft rules involving ct helper set or NAT entries.

Short-term mitigations (if immediate patching is not feasible):

• Avoid the problematic rule ordering: prefer assigning helpers before applying DNAT/SNAT rules in nft rulesets when practical.
• Restrict who can install or modify conntrack helpers and NAT rules (RBAC for orchestration tooling, hardened CI pipelines).
• For critical appliances, test vendor-supplied images for the presence of the upstream commit or explicitly request vendor confirmation of the backport.

---

Vendor status, patches and Microsoft’s (MSRC) presence​

Multiple independent sources (NVD, OSV, Patchew / kernel mailing lists) show the upstream change and the CVE assignment. OSV and CVE aggregators include CVE-2025-68206 with matching summaries and the NVD published entry shows kernel.org references. The Microsoft Security Response Center (MSRC) page for CVE-2025-68206 might not render as a static page for automated fetchers and, at the time of writing, direct access to the MSRC update-guide URL returns a client-side JavaScript page (the portal requires JS to render). That dynamic behavior can make single-page snapshots appear “not found” to crawlers even when the item is present in the MSRC system or pending publishing. Administrators who rely on MSRC for vendor attestations should check the MSRC web UI or the Security Update Guide API with an active browser session to confirm whether Microsoft has published an attestation or mapping for this specific CVE. A practical word of caution: vendor attestations (for example Azure Linux) are product‑level inventory statements — they confirm that a particular product family includes the upstream component and therefore may be affected. Absence of an attestation for other products is not proof they are safe; it usually means the vendor has not yet completed that artifact’s inventory. Treat vendor VEX/CSAF outputs as authoritative where present, and as incomplete where absent; perform independent checks (kernel version, config and package changelog) for your specific images and hosts.

---

Practical remediation plan (prioritized)​

• Inventory: locate systems that run kernels with nftables, conntrack helpers, and NAT enabled.
• Commands: uname -a ; grep -E 'NF_CONNTRACK|CONNTRACK|CTNETLINK' /boot/config-$(uname -r) or zcat /proc/config.gz | grep -E 'NF_CONNTRACK|CTNETLINK'.
• Map: compare your kernel package versions to vendor advisories (distribution security trackers, OSV, NVD) to identify patched package versions.
• Patch: apply vendor kernel updates or distribution packages that include the upstream fix and reboot into the patched kernel.
• Validate: in a test environment, reproduce the earlier example ruleset and verify that PASV/EPSV sessions survive NAT rewriting without connection failure and without kernel WARN traces.
• Harden: restrict who may install helpers or NAT mappings; enforce change control for nft rule deployments.

Also consider the following short-term mitigations if you cannot patch immediately:

• Reorder rules to assign the helper before applying DNAT/SNAT for the affected flows.
• Limit FTP control-channel manipulation or prefer stateful application-layer proxies that handle FTP rewriting outside the kernel.

A concise checklist with commands and verification steps was included in multiple vendor-tracking advisories and community write-ups; follow the vendor package mapping for exact patched package identifiers before patching production systems.

---

Strengths of the fix and residual risks​

Strengths​

• The change is minimal and focused: create seqadj at the exact moment the helper is assigned for NAT’ed conntrack — small diffs are easier to review and backport into stable kernel branches.
• Defensible semantics: the upstream design always ensures an explicit extension is present rather than relying on brittle ordering assumptions between helper assignment and NAT setup.
• Low regression risk: reviewers favored a narrowly scoped approach, which reduces the chance of unintended behavior elsewhere in the NAT stack. Patch discussions emphasize careful testing and predictable verdict handling.

Residual risks and caveats​

• Vendor lag and backport variance: embedded and appliance kernels, vendor-modified images, and old stable branches may not receive immediate backports. Operators must verify package changelogs rather than relying solely on CVE numbers.
• Complex rule deployments: environments that dynamically generate nft rules via orchestration platforms still risk transient windows where helper assignment and NAT bindings interleave poorly. Auditing and ordering rules at generation time helps mitigate this.
• Detection limitations: functional failures can be transient and may be misattributed to application issues; centralized kernel log capture and orchestration-change telemetry are important for accurate root cause mapping.

---

How to verify you are safe (technical checks)​

• Confirm kernel package includes the upstream commit: check your distribution’s kernel changelog for references to the upstream commit hash or the CVE identifier.
• Inspect runtime kernel objects:
• Check if conntrack helpers and NAT are enabled: lsmod | grep conntrack ; nft list ruleset | grep helper
• Run a controlled PASV/EPSV FTP session through a test NAT and capture kernel logs (journalctl -k) for missing seqadj warnings.
• For WSL2 or vendor-provided kernels: check the WSL kernel release tag or vendor kernel mapping and request vendor confirmation if the kernel is a Microsoft-supplied artifact (Azure Linux, CBL‑Mariner, or WSL kernel). Microsoft’s product attestations can be helpful where present but are not exhaustive; cross-check vendor package changelogs as the final authority.

---

Conclusion​

CVE-2025-68206 is a focused upstream fix that corrects a practical sequencing error in nftables’ conntrack machinery: the kernel now ensures a seqadj extension is provisioned for NAT’ed conntrack helpers so FTP PASV/EPSV payload rewrites maintain TCP sequence coherence. The change is low-risk and readily backportable, but operators must act: patch vendor kernels, validate rule ordering in nft scripts, and audit appliances and cloud images that perform application-layer NAT rewrites.
Relying on vendor attestations helps, but they are only one input — operators must verify kernel/package changelogs and test critical FTP NAT workflows. The upstream patch and the associated mailing-list discussion demonstrate that the fix is intentional and narrowly scoped; the real operational work is inventorying affected systems, applying vendor backports, and validating behavior in environments that still rely on kernel-based FTP helpers.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center