Cloudanix VulnDB

CVE-2025-68206

None

CVSS

—

EPSS

0.7%

Published

Dec 16, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's network address translation handling can break passive FTP file transfers through certain gateway configurations, causing connections to drop unexpectedly.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Missing call to nfct_seqadj_ext_add() when a conntrack helper is assigned after NAT binding on a connection, preventing required TCP sequence adjustment for payload-rewriting protocols such as FTP PASV/EPSV.

Why it matters to the business

FTP transfers through NAT gateways using conntrack helpers fail with connection resets or service unavailable errors, disrupting file transfers and automated workflows that rely on passive FTP.

How an attack unfolds

An attacker triggers the condition by initiating an FTP control connection through a NAT device configured with both a conntrack FTP helper and destination NAT; the missing sequence adjustment extension causes the kernel to drop or mangle subsequent data connections, resulting in failed transfers.

How to fix it

Upgrade to a kernel containing commit 4ab2cd906e4e1a19ddbda6eb532851b0e9cda110 or later; for Chainguard ztunnel-fips-1.24 and ztunnel-fips-1.24-compat use version 1.24.3-r1 or newer. Ensure nftables and netfilter rules assign helpers after NAT bindings where possible.

How to confirm the fix worked

Confirm the presence of nfct_seqadj_ext_add() in nf_nat_setup_info() and nf_conntrack_ftp paths; test FTP PASV transfers through the affected NAT ruleset and verify absence of the nf_conntrack_seqadj.c warning.

Typical attack path

  1. Configure NAT rules that perform destination NAT on TCP port 21 before or without ensuring conntrack helper assignment order.
  2. Initiate FTP control connection and issue PASV or EPSV command.
  3. FTP server responds with a data port; helper attempts to mangle the payload without sequence adjustment support.
  4. Kernel logs warning and data connection fails with 421 error or reset.

How to detect it

Search kernel logs for the warning string "Missing nfct_seqadj_ext_add() setup call" and stack traces involving nf_nat_ftp and nf_conntrack_ftp; inspect nftables rulesets containing both ct helper and nat statements on port 21.

What your security team should do

  • Prioritize kernel upgrades on all NAT gateways and load balancers handling FTP.
  • Review and reorder nftables rules to assign conntrack helpers after NAT decisions.
  • Monitor kernel logs for nf_conntrack_seqadj warnings on systems performing FTP NAT.
  • Temporarily disable FTP conntrack helpers if FTP NAT functionality is non-critical.

The record

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: add seqadj extension for natted connections Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq. The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" } } table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } } } Note that the ftp helper gets assigned *after* the dnat setup. The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem. Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection. Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 .. Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 4.12.0 6.12.64
Linux Kernel 4.12.0 6.17.9
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-azure 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.9.1.160000.2.6
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.9.1

Related vulnerabilities