From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792759245; b=fcohRksIQ+DzWvbHW2pecr+d5EsORtz58TfAr9ipNPQgrIMbvtaVgKYeJyFL9WtJcynX RQnfIHp3d+jOEGoFGLzuXZvUSwCppUBOXQDsCDr+W06/TjSxMxzk9ddrkifXU2Sy0Nph3 iPo9e6XlHt/RL6NVWVJxG6gdyPQFf5vD5OqCMQPLtAj/JD+bCdz/Rrcemo0wx7nYxB7WT JoFBUtdE0/gC6GCFs0KJL1mAPJ2PxgHF0Yz+lzBUv14wv3L6SC6I0ZOn4ZvxDPP+zRW7c DvO3eyrQXPl7k+Pyt3rXHtsPR90B11Om4IrUCYJ1q+Wy5amDvJ4Vg7obfjAx17ojpPA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792759245; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: Reply-To:MIME-Version:Lines:X-Developer-Signature:X-Developer-Key: Content-Transfer-Encoding; bh=wqdxxcfkB+1pfDRA1IfdHs5hOd64d02tTFiZ3Xj2CWc=; b=lGmsWXH6bIhrDbeLnO+eui+TBhxQzcQGYB+akrxwO9iyIUkjhWvLxYrjJhEQRk/JMPGu QNZWrOb6qWN0XRx1uOuezh6L/EHc6ES+HVwEY6/LvsK7FLZtJ33upEPzbeOa4PWKdHuk7 kvMDHvT7UnbMb+c52Zn0baQ1zeVuexSqmXKevb34SJtHqpc27tXnmX95tkbsvJ/SFTpQe qzLmONf1gMjP91CuCzg4p81jH5IkL8xDNOngXah2CtIG785f3eX3Rc+aHoFQIrESBCEPp rDMzzexNVr0BUNdbw23cYihxYbv2fvE+WklKYWNZXAmxpwl+x+fg5QWPUnXNeo+HnDg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=W54kj01j; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC589606A320 for ; Fri, 23 Oct 2026 12:40:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=W54kj01j Received: by smtp.kernel.org (Postfix) with ESMTPSA id D93D01F01825; Fri, 23 Oct 2026 12:40:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1792759244; bh=wqdxxcfkB+1pfDRA1IfdHs5hOd64d02tTFiZ3Xj2CWc=; h=From:To:Cc:Subject:Date:Reply-To; b=W54kj01jLajYtTmqBDSfGBvwEZd6mtyKRonVf9BFEaFf/ph76gfyxhD3729i20uUU UlT9zeQUYLBKl4icxjap7mWB3SuQ+x/F3FjP6wZJObQKRoCQDA2vsJRygawXgUM0Q3 agcQVLxNsvr96SsM3VDY0L9m+At5zrrAApz+uAT4= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-99059: wireguard: noise: reject response consumption after intermediate initiation Date: Fri, 23 Oct 2026 14:21:01 +0200 Message-ID: <2026102331-CVE-2026-99059-dd6d@gregkh> X-Mailer: git-send-email 2.56.0 Reply-To: , X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=4410; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=9L8uOY+YZxdS6wZVTSgn1jSCS12HnfwoYE8iZP4zJ4U=; b=owGbwMvMwCRo6H6F97bub03G02pJDFm3Ay4viXLuKSpWD9W4s4K5cXmUudb0vGUhjy6L7hAWb FuzPjy7I5aFQZCJQVZMkeXLNp6j+ysOKXoZ2p6GmcPKBDKEgYtTACZyaDfDgnPKqR28W0+rbfvz pcY7VMKknut5GMM8cwHDCkFTW0tvK0nFqTx5P//sudwDAA== X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman 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. The Linux kernel CVE team has assigned CVE-2026-99059 to this issue. Affected and fixed versions =========================== Issue introduced in 5.6 with commit e7096c131e5161fa3b8e52a650d7719d2857adfd and fixed in 6.6.160 with commit fb5ce4c7790c3eeec820302d08d70ecf46af4295 Issue introduced in 5.6 with commit e7096c131e5161fa3b8e52a650d7719d2857adfd and fixed in 6.12.113 with commit c76a80db593096edf2b3b3972f58b6342a8c6c04 Issue introduced in 5.6 with commit e7096c131e5161fa3b8e52a650d7719d2857adfd and fixed in 6.18.57 with commit 4d64a3d6e96aa78619c9c29ffde309794974588a Issue introduced in 5.6 with commit e7096c131e5161fa3b8e52a650d7719d2857adfd and fixed in 7.2.11 with commit 3bec3d32c2a3afd164fc87f95457df2cf9049c20 Issue introduced in 5.6 with commit e7096c131e5161fa3b8e52a650d7719d2857adfd and fixed in 7.3 with commit d0305f8d90029556260c6824b61c493c424eba9e Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-99059 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: drivers/net/wireguard/noise.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/fb5ce4c7790c3eeec820302d08d70ecf46af4295 https://git.kernel.org/stable/c/c76a80db593096edf2b3b3972f58b6342a8c6c04 https://git.kernel.org/stable/c/4d64a3d6e96aa78619c9c29ffde309794974588a https://git.kernel.org/stable/c/3bec3d32c2a3afd164fc87f95457df2cf9049c20 https://git.kernel.org/stable/c/d0305f8d90029556260c6824b61c493c424eba9e