CVE-2026-90237: netfilter: nft_ct: move custom expectation support to helper
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftct: move custom expectation support to helper
Originally, the ct expectation support called nfcthelperextadd() for confirmed conntracks, which is invalid, triggering a splat. This was fixed by commit 1710eb913bdc ("netfilter: nftct: 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 hlisthead through .pprev due to ct extension reallocation.
Commit 7c9664351980 ("netfilter: move nat hlisthead to nfconn") moved the nat hlisthead to nfconn for this reason:
1. ... 2. When reallocation of extension area occurs we need to fixup the bysource hash head via hlistreplacercu.
I'd rather not increase the size of the struct nfconn for this feature has very limited scope: only one expectation can be created at a time given expectclash() will make nfctexpectrelated() reports EBUSY. For this reason, relax nfctexpectrelated() 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 nfconntrackhelperrelease() function to release the internal helper that is allocated and attached to the conntrack entry to create the custom expectations. The nftct 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.
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel netfilter nft_ct connection-tracking expectation support are relevant. The issue is tied to custom expectation handling for conntracks while they are unconfirmed.
What condition triggers the faulty state?
The problem occurs when an expectation is inserted while a conntrack is unconfirmed and the conntrack extension area is later reallocated. That can leave a stale expectations-list entry with a .pprev reference to the wrong hlist_head.
Does failed expectation creation necessarily drop traffic?
No. The described change relaxes nf_ct_expect_related() so that packets are not dropped when expectation creation fails.