{"apiVersion":"1.0","identifier":"CVE-2026-99059","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.","publishedAt":"2026-10-23T13:17:29","lastModifiedAt":"2026-10-30T13:21:42","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-99059","cvssScore":7.7,"cvssVector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L","epssProbability":0.00506,"riskScore":0.81,"affectedProduct":"Linux kernel","affectedVersions":"unknown","vulnerabilityType":"Kernel","operatingSystems":[],"links":{"self":"https://www.redsauce.net/api/cves/CVE-2026-99059","webPages":{"es":"https://www.redsauce.net/es/cves/CVE-2026-99059","en":"https://www.redsauce.net/en/cves/CVE-2026-99059","fr":"https://www.redsauce.net/fr/cves/CVE-2026-99059","pt":"https://www.redsauce.net/pt/cves/CVE-2026-99059","de":"https://www.redsauce.net/de/cves/CVE-2026-99059","sk":"https://www.redsauce.net/sk/cves/CVE-2026-99059","el":"https://www.redsauce.net/el/cves/CVE-2026-99059"},"source":"https://nvd.nist.gov/vuln/detail/CVE-2026-99059"}}