ghsa-9r97-6c49-v2hf
Vulnerability from github
Published
2025-12-16 15:30
Modified
2025-12-16 15:30
Details

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.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2025-68206"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-16T14:15:53Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: add seqadj extension for natted connections\n\nSequence adjustment may be required for FTP traffic with PASV/EPSV modes.\ndue to need to re-write packet payload (IP, port) on the ftp control\nconnection. This can require changes to the TCP length and expected\nseq / ack_seq.\n\nThe easiest way to reproduce this issue is with PASV mode.\nExample ruleset:\ntable inet ftp_nat {\n        ct helper ftp_helper {\n                type \"ftp\" protocol tcp\n                l3proto inet\n        }\n\n        chain prerouting {\n                type filter hook prerouting priority 0; policy accept;\n                tcp dport 21 ct state new ct helper set \"ftp_helper\"\n        }\n}\ntable ip nat {\n        chain prerouting {\n                type nat hook prerouting priority -100; policy accept;\n                tcp dport 21 dnat ip prefix to ip daddr map {\n\t\t\t192.168.100.1 : 192.168.13.2/32 }\n        }\n\n        chain postrouting {\n                type nat hook postrouting priority 100 ; policy accept;\n                tcp sport 21 snat ip prefix to ip saddr map {\n\t\t\t192.168.13.2 : 192.168.100.1/32 }\n        }\n}\n\nNote that the ftp helper gets assigned *after* the dnat setup.\n\nThe inverse (nat after helper assign) is handled by an existing\ncheck in nf_nat_setup_info() and will not show the problem.\n\nTopoloy:\n\n +-------------------+     +----------------------------------+\n | FTP: 192.168.13.2 | \u003c-\u003e | NAT: 192.168.13.3, 192.168.100.1 |\n +-------------------+     +----------------------------------+\n                                      |\n                         +-----------------------+\n                         | Client: 192.168.100.2 |\n                         +-----------------------+\n\nftp nat changes do not work as expected in this case:\nConnected to 192.168.100.1.\n[..]\nftp\u003e epsv\nEPSV/EPRT on IPv4 off.\nftp\u003e ls\n227 Entering passive mode (192,168,100,1,209,129).\n421 Service not available, remote server has closed connection.\n\nKernel logs:\nMissing nfct_seqadj_ext_add() setup call\nWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41\n[..]\n __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat]\n nf_nat_ftp+0x142/0x280 [nf_nat_ftp]\n help+0x4d1/0x880 [nf_conntrack_ftp]\n nf_confirm+0x122/0x2e0 [nf_conntrack]\n nf_hook_slow+0x3c/0xb0\n ..\n\nFix this by adding the required extension when a conntrack helper is assigned\nto a connection that has a nat binding.",
  "id": "GHSA-9r97-6c49-v2hf",
  "modified": "2025-12-16T15:30:45Z",
  "published": "2025-12-16T15:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68206"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2b52d89cbbb0dbe3e948d8d9a91e704316dccfe6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/90918e3b6404c2a37837b8f11692471b4c512de2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…