wireguard-nt, 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

api: rundll32: manage replies from worker process better

2026-07-20T13:39:58Z

CommandLineToArgvW("") returns the calling executable's path with Argc=1, so a silent worker crash would be parsed as a path through wcstoul, yielding either bogus error codes or, on UNC paths, a silent ERROR_SUCCESS. Also deal with a zero sized response buffer, and the case when the response fills the buffer precisely. Signed-off-by: Jason A. Donenfeld

api: adapter: pin the module across background orphan cleanup

2026-07-14T14:31:53Z

AdapterCleanupOrphanedDevices(TRUE) is called from DllMain's DLL_PROCESS_ATTACH and queues CleanupOrphanedDevices onto a thread-pool thread, where it runs long SetupAPI/CM operations and blocks on the namespace mutexes. Pin the module before this happens, so that it can't be unloaded while working. Signed-off-by: Jason A. Donenfeld

api: cleanup phantom devices added by windows updates

2026-07-14T14:26:52Z

When Windows does major updates, it walks the driver store and manually installs drivers into the ROOT namespace. This is a problem since we use the SWD namespace. Since these nodes are never accounted for, they live on and prevent the driver from ever being unloaded or upgraded. Fix this by walking through the ROOT namespace and removing these phantom drivers. Signed-off-by: Jason A. Donenfeld

version: bump

2026-05-07T12:17:00Z

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