wireguard: noise: reject response consumption after intermediate initiation
Severity and exploitation
KEV coverage does not rule out exploitation.
Assessment vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:LSeverity
high7.7CVSS measures technical severity, not the likelihood of an attack.
Known exploitation
Not listed in the checked CISA KEV catalog
Absence from CISA KEV does not rule out attacks.
Public exploit
Not established by this record
Missing evidence does not mean no public exploit exists.
Remediation
Fix status not established
No structured fix or guidance is available here. Check the latest publisher advisory.
What this means
A vulnerability in Linux kernel's WireGuard noise protocol allows two threads to process the same response message, potentially leading to a race condition. The affected versions are Linux kernel 5.6 and later, up to but not including 5.10.273, 5.15.224, 6.1.191, 6.6.160, 6.12.113, 6.18.57, 7.2.11, and 7.3. The impact is unclear.
Summarized by @cf/meta/llama-3.3-70b-instruct-fp8-fast. Verify details against the original sources.Attack conditions
No attack-condition excerpt has been identified here. Review the full source description and references for authentication, network access, and configuration requirements.
Review supporting sources →Affected versions
Check the exact model, release, and any platform requirements against your installation.
Linux · Linux
Linux
8 ranges
Linux · Linux
Linux
Compare with this publisher’s ranges. This does not inspect your installation.
affected
e7096c131e5161fa3b8e52a650d7719d2857adfd → before dbd1e21f4301bd2157cd771255f1ca6ba1c8a1f9
git versions
e7096c131e5161fa3b8e52a650d7719d2857adfd → before f4012ec25a4abb6a23dc40043f61e2d9a7deca6d
git versions
e7096c131e5161fa3b8e52a650d7719d2857adfd → before 6b5b14cb5421e84191e3f6b5a7566783a402ff7f
git versions
e7096c131e5161fa3b8e52a650d7719d2857adfd → before fb5ce4c7790c3eeec820302d08d70ecf46af4295
git versions
e7096c131e5161fa3b8e52a650d7719d2857adfd → before c76a80db593096edf2b3b3972f58b6342a8c6c04
git versions
e7096c131e5161fa3b8e52a650d7719d2857adfd → before 4d64a3d6e96aa78619c9c29ffde309794974588a
git versions
e7096c131e5161fa3b8e52a650d7719d2857adfd → before 3bec3d32c2a3afd164fc87f95457df2cf9049c20
git versions
e7096c131e5161fa3b8e52a650d7719d2857adfd → before d0305f8d90029556260c6824b61c493c424eba9e
git versions
Other versions: unaffected
Linux · Linux
Linux
10 ranges
Linux · Linux
Linux
Compare with this publisher’s ranges. This does not inspect your installation.
affected
5.6
unaffected
0 → before 5.6
semver versions
5.10.273 → through 5.10.*
semver versions
5.15.224 → through 5.15.*
semver versions
6.1.191 → through 6.1.*
semver versions
6.6.160 → through 6.6.*
semver versions
6.12.113 → through 6.12.*
semver versions
6.18.57 → through 6.18.*
semver versions
7.2.11 → through 7.2.*
semver versions
7.3 → through *
original_commit_for_fix versions
Other versions: affected
What to do
Compare your installed product and version with the affected versions above. A matching product name alone does not confirm exposure.
No structured fix or remediation guidance is available here. Check the full source description and vendor’s latest advisory for a patch or workaround; do not assume another version is safe.
cve.new guidance unless attributed to a publisher. This page does not inspect your installation.
Public exploit evidence
No public exploit reference is identified in the imported evidence. This is not a claim that no exploit exists.
Original source description
Read the full publisher description
In the Linux kernel, the following vulnerability has been resolved:
wireguard: noise: reject response consumption after intermediate initiation
Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on down_write(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same down_write(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls up_write(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire down_write(). Thread B then copies the state back to the peer, and begins a new session, using that state, which is the same session as the one made in thread A.
Thread A Thread B Thread C
down_read() sA = handshake->state memcpy(cA, handshake->crypto) up_read() if (sA != 1) goto fail slow_crypto(cA) down_read() sB = handshake->state memcpy(cB, handshake->crypto) up_read() if (sB != 1) goto fail slow_crypto(cB) down_write() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() down_write() slow_crypto(handshake->crypto) handshake->state = 1 up_write() down_write() if (sB != handshake->state) goto fail memcpy(handshake->crypto, cB) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write()
This seems basically impossible to hit in a meaningful way in practice, but ensure that it absolutely cannot happen by comparing the ephemeral private key that's on the stack with the latest one that the peer's handshake state has.
References
8 sourcesInside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-99059View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →Environment requirements
These conditions apply together as specified by the publisher. A matching product name alone does not establish exposure.
Linux · platform conditions
Any condition may hold
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 5.6
Before: 5.10.273
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 5.6
Before: 5.15.224
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 5.6
Before: 6.1.191
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 5.6
Before: 6.6.160
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 5.6
Before: 6.12.113
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 5.6
Before: 6.18.57
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 5.6
Before: 7.2.11
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 5.6
Before: 7.3
Applicability preview
[
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.6",
"versionEndExcluding": "5.10.273"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.6",
"versionEndExcluding": "5.15.224"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.6",
"versionEndExcluding": "6.1.191"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.6",
"versionEndExcluding": "6.6.160"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.6",
"versionEndExcluding": "6.12.113"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.6",
"versionEndExcluding": "6.18.57"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.6",
"versionEndExcluding": "7.2.11"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.6",
"versionEndExcluding": "7.3"
}
]
}
]
}
]Contributing organizations · 1
Assigning organization
Timeline
All times UTCAdvisory published
Publication date supplied by the source.
Source updated
Latest modification date supplied by the source.
Last imported by cve.new
Latest catalog import, not the date we first saw this advisory.
What changed
Follow changesLarge field values are marked as truncated previews. Original source snapshots remain retained.