CVE-2026-43116: netfilter: ctnetlink: ensure safe access to master conntrack
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: ensure safe access to master conntrack
Holding reference on the expectation is not sufficient, the master
conntrack object can just go away, making exp->master invalid.
To access exp->master safely:
- Grab the nf_conntrack_expect_lock, this gets serialized with
clean_from_lists() which also holds this lock when the master
conntrack goes away.
- Hold reference on master conntrack via nf_conntrack_find_get().
Not so easy since the master tuple to look up for the master conntrack
is not available in the existing problematic paths.
This patch goes for extending the nf_conntrack_expect_lock section
to address this issue for simplicity, in the cases that are described
below this is just slightly extending the lock section.
The add expectation command already holds a reference to the master
conntrack from ctnetlink_create_expect().
However, the delete expectation command needs to grab the spinlock
before looking up for the expectation. Expand the existing spinlock
section to address this to cover the expectation lookup. Note that,
the nf_ct_expect_iterate_net() calls already grabs the spinlock while
iterating over the expectation table, which is correct.
The get expectation command needs to grab the spinlock to ensure master
conntrack does not go away. This also expands the existing spinlock
section to cover the expectation lookup too. I needed to move the
netlink skb allocation out of the spinlock to keep it GFP_KERNEL.
For the expectation events, the IPEXP_DESTROY event is already delivered
under the spinlock, just move the delivery of IPEXP_NEW under the
spinlock too because the master conntrack event cache is reached through
exp->master.
While at it, add lockdep notations to help identify what codepaths need
to grab the spinlock.
Security readout for executives and security teams
Plain-English summary
A Linux kernel race can leave netfilter’s connection-tracking code using a master connection object after it has disappeared. A local, low-privileged attacker may be able to trigger serious confidentiality, integrity, or availability impact. The supplied CVSS score is 7.8 (high), but the sources provide no evidence of active exploitation.
Executive priority
Treat this as a high-priority kernel maintenance issue, especially for multi-user or workload-hosting systems. Schedule expedited vendor-supported updates after confirming affected package mappings. Emergency incident response is not justified from this bundle alone because active exploitation is not reported.
Technical view
Ctnetlink expectation add, delete, get, and event paths could access exp->master without adequate lifetime protection. Holding an expectation reference did not keep the master conntrack alive. The fix extends nf_conntrack_expect_lock coverage around expectation lookup and event delivery, serializing access with master cleanup and adding lockdep assertions.
Likely exposure
Exposure is most relevant on systems running an affected Linux kernel where a local, low-privileged actor can reach ctnetlink expectation handling. The bundle identifies affected version entries including 2.6.16, 6.1.176, 6.6.143, 6.12.94, 6.18.24, 6.19.14, and 7.0, but does not provide clear distribution-package mappings.
Exploitation context
The CVSS vector indicates local access, low complexity, low privileges, no user interaction, and potentially high confidentiality, integrity, and availability impact. KEV is false, and none of the supplied sources reports exploitation in the wild or provides confirmed exploitability details.
Researcher notes
This is a concurrency and object-lifetime flaw involving expectation-table operations and master conntrack cleanup. The upstream correction relies primarily on broader spinlock coverage rather than reconstructing a tuple for nf_conntrack_find_get(). The bundle does not identify a CWE, trigger reliability, affected distribution packages, public proof of concept, or observed attacks.
Mitigation direction
Install the distribution or vendor kernel update containing the applicable stable fix.
Match the running kernel build against vendor advisories; upstream version entries may not reflect backports.
Prioritize shared or untrusted multi-user systems where local low-privileged access exists.
If patching is delayed, review vendor guidance for supported temporary mitigations.
Validation and detection
Record each system’s exact kernel release, build, and distribution package revision.
Confirm through vendor advisories whether the applicable stable commit was backported.
Verify the updated kernel is installed and currently booted.
Review kernel logs for conntrack, netfilter, memory-safety, or unexpected crash indicators.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43116 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.