Linux Kernel up to 7.2.5 nft_ct nf_conntrack_helper_release allocation of resources

Summaryinfo

A vulnerability categorized as very critical has been discovered in Linux Kernel up to 7.2.5. The affected element is the function nf_conntrack_helper_release of the component nft_ct. The manipulation results in allocation of resources. This vulnerability is cataloged as CVE-2026-90237. The attack may be launched remotely. There is no exploit available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability classified as very critical has been found in Linux Kernel up to 7.2.5. Affected is the function nf_conntrack_helper_release of the component nft_ct. The manipulation with an unknown input leads to a allocation of resources vulnerability. CWE is classifying the issue as CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. This is going to have an impact on confidentiality, integrity, and availability. CVE summarizes:

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: move custom expectation support to helper Originally, the ct expectation support called nf_ct_helper_ext_add() for confirmed conntracks, which is invalid, triggering a splat. This was fixed by commit 1710eb913bdc ("netfilter: nft_ct: skip expectations for confirmed conntrack") which restricted it to unconfirmed conntracks. However, early insertion of expectations into the expectations list when the conntrack is unconfirmed leads to stale entries pointing to the wrong hlist_head through .pprev due to ct extension reallocation. Commit 7c9664351980 ("netfilter: move nat hlist_head to nf_conn") moved the nat hlist_head to nf_conn for this reason: 1. ... 2. When reallocation of extension area occurs we need to fixup the bysource hash head via hlist_replace_rcu. I'd rather not increase the size of the struct nf_conn for this feature has very limited scope: only one expectation can be created at a time given expect_clash() will make nf_ct_expect_related() reports EBUSY. For this reason, relax nf_ct_expect_related() not to drop packets in case expectation creation fails, therefore, expectation creation becomes best effort. To address this issue, add an internal ct helper and attach it to the conntrack entry to streamline the custom ct expectation support with existing ct helpers. Expose a new nf_conntrack_helper_release() function to release the internal helper that is allocated and attached to the conntrack entry to create the custom expectations. The nft_ct module removal always waits for rcu grace period, then the NULL helper callback is observed after this. This patch also restricts the creation of expectations to different helpers other than this custom helper that is created for this type of expectations.

The advisory is shared for download at git.kernel.org. This vulnerability is traded as CVE-2026-90237 since 09/11/2026. The exploitability is told to be easy. It is possible to launch the attack remotely. The exploitation doesn't require any form of authentication. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 09/17/2026). The MITRE ATT&CK project declares the attack technique as T1499.

Upgrading to version 7.2.6 or 7.3-rc1 eliminates this vulnerability. Applying the patch af3fe52fd108fd38235e4813df62442ed0f1d8ff/3679da4ad8be84cddaf40bc307fef1fe13e051ff is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.2.0
• 7.2.1
• 7.2.2
• 7.2.3
• 7.2.4
• 7.2.5

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion