wireguard-nt/driver, branch master

driver: noise: reject response consumption after intermediate initiation

2026-10-06T16:33:02Z

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 MuAcquirePushLockExclusive(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same MuAcquirePushLockExclusive(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls MuReleasePushLockExclusive(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire MuAcquirePushLockExclusive(). 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 MuAcquirePushLockShared() sA = Handshake->State RtlCopyMemory(cA, Handshake->crypto) MuReleasePushLockShared() if (sA != 1) goto fail SlowCrypto(cA) MuAcquirePushLockShared() sB = Handshake->State RtlCopyMemory(cB, Handshake->crypto) MuReleasePushLockShared() if (sB != 1) goto fail SlowCrypto(cB) MuAcquirePushLockExclusive() if (sA != Handshake->State) goto fail RtlCopyMemory(Handshake->crypto, cA) Handshake->State = 2 MuReleasePushLockExclusive() MuAcquirePushLockExclusive() if (Handshake->State != 2) goto fail DeriveSession(Handshake->crypto) MuReleasePushLockExclusive() MuAcquirePushLockExclusive() SlowCrypto(Handshake->crypto) Handshake->State = 1 MuReleasePushLockExclusive() MuAcquirePushLockExclusive() if (sB != Handshake->State) goto fail RtlCopyMemory(Handshake->crypto, cB) Handshake->State = 2 MuReleasePushLockExclusive() MuAcquirePushLockExclusive() if (Handshake->State != 2) goto fail DeriveSession(Handshake->crypto) MuReleasePushLockExclusive() 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. Signed-off-by: Jason A. Donenfeld

driver: ioctl: reset IsDeviceRemoving on cancel-remove

2026-07-20T13:39:58Z

Otherwise a vetoed query-remove leaves the adapter permanently inaccessible via ioctl, even though NDIS keeps the miniport alive and operational. Signed-off-by: Jason A. Donenfeld

driver: nsi: forward IRPs instead of failing

2026-05-07T12:17:00Z

We always have a file reference to get the proper nsi device object, so rather than failing, in most cases, we can properly service these requests. Signed-off-by: Jason A. Donenfeld

driver: nsi: compare FilterDevice pointers under rundown protection

2026-05-07T12:17:00Z

And also gate the PriorDispatch on the presence of an extension, which NDIS always has. Reported-by: Brian Diff Signed-off-by: Jason A. Donenfeld

driver: nsi: re-initialize rundown protection atomically

2026-05-07T12:17:00Z

Signed-off-by: Jason A. Donenfeld

driver: noise: remove unused StaticPrivate variable

2026-04-29T01:01:39Z

The stack version of this is never used, because it's long-lived, and so we always read it out of the peer struct. Signed-off-by: Jason A. Donenfeld

driver: remove unused prefast suppressions

2026-04-21T19:18:21Z

Signed-off-by: Jason A. Donenfeld

driver: remove fixed codeql suppressions

2026-04-21T13:34:48Z

I fixed the CodeQL rules. Link: https://github.com/microsoft/Windows-Driver-Developer-Supplemental-Tools/pull/217 Signed-off-by: Jason A. Donenfeld

driver: socket: note that stack Endpoint is safe in SocketSendBufferAsReplyToNbl

2026-04-16T10:12:37Z

WSK's WskSendTo copies addresses and control messages synchronously before returning STATUS_PENDING. Confirmed by reverse engineering afd.sys!WskProIRPSendTo and tcpip.sys!UdpSendMessages, which consume address and cmsg data in the transport dispatch call and store only the completion callback and IRP in the NBL context. Signed-off-by: Jason A. Donenfeld

driver: allowedips: return STATUS_SUCCESS instead of 0

2026-04-16T00:34:57Z

Signed-off-by: Jason A. Donenfeld