wintun, branch master

driver: fix missed-wakeup race in ring buffer Alertable signaling

2026-03-18T17:49:30Z

Add MemoryBarrier() between store-load pairs in the Dekker-style synchronization used by the Receive ring's Alertable/Tail protocol. On x86-64, WriteRelease/ReadAcquire only prevent compiler reordering and provide acquire/release semantics, but do not emit MFENCE — the only instruction that prevents store-load reordering across cores. Without a full barrier, both the userspace producer and the kernel consumer can simultaneously read stale values: Userspace: STORE(Tail) ... LOAD(Alertable) -> sees FALSE (stale) Driver: STORE(Alertable=TRUE) ... LOAD(Tail) -> sees old tail The driver then enters KeWaitForMultipleObjects with no pending SetEvent, sleeping until a TCP retransmission (typically 4-5s later) re-triggers the send path and wins the race. The fix adds MemoryBarrier() (MFENCE on x86) on both sides: - api/session.c WintunSendPacket: between WriteULongRelease(Tail) and ReadAcquire(Alertable) - driver/twintun.c TunProcessReceiveData: between WriteRelease(Alertable, TRUE) and ReadULongAcquire(Tail) This guarantees that at least one side always observes the other's store, preventing the missed wakeup while preserving the Alertable optimization that avoids unnecessary SetEvent syscalls. Reported-by: Alexey Lapuka Reference: https://lists.zx2c4.com/pipermail/wireguard/2026-February/009523.html Signed-off-by: Simon Rozman

driver: fix race condition at Ring->Head

2026-02-20T13:30:57Z

This PR fixes a critical race condition in the Wintun driver that causes ring buffer overruns when multiple UDP senders operate in parallel. The issue occurred because multiple threads could read the same Ring->Head value without synchronization, leading to concurrent modifications that corrupted the ring buffer and resulted in ERROR_INVALID_DATA errors. In order to prevent buffer overrun (which was observed while sending multiple high throughput UDP streams from different threads) I move the driver spinlock to protect Ring buffer Head. I observed that the Ring->Head was taken and manipulated later on with just a `ReadULongAcquire` which isn't OK when 2 are trying to manipulate it later on based on the same received value. A fix was provided in 4fc590853b8281552631b79dacda484a5782f3bf, but it didn't solve the issue. Reported-by: odedkatz Reference: https://lists.zx2c4.com/pipermail/wireguard/2026-February/009489.html Reference: https://lists.zx2c4.com/pipermail/wireguard/2026-February/009510.html Signed-off-by: Simon Rozman

driver: explicitly terminate NBL

2026-02-20T13:10:55Z

The ActiveNbls list uses MINIPORT_RESERVED[1] as the next pointer, but never NULL-terminates the tail entry. It was never observed the allocated NBL would contain a non-zero MiniportReserved array, but this being unspecified in the official documentation, let's stay out of "unspecified" area. Reference: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/nbl/ns-nbl-net_buffer_list Signed-off-by: Simon Rozman

driver: introduce NET_BUFFER_LIST_OFFSET helper

2026-02-09T11:41:08Z

Since NET_BUFFER_LIST_MINIPORT_RESERVED[1] is assigned our next NBL pointer and we have a macro for it (NET_BUFFER_LIST_NEXT_NBL_EX), let's have a macro for NET_BUFFER_LIST_MINIPORT_RESERVED[0], we assigned NBL offset and flags to, too. Signed-off-by: Simon Rozman

doc: fix WintunReceivePacket name

2026-02-09T10:24:51Z

There is no `WintunReceivePackets`. Just `WintunReceivePacket`. Signed-off-by: Simon Rozman

api: ignore instance not found when removing instance

2025-05-21T08:34:59Z

Should SetupAPI report ERROR_PATH_NOT_FOUND on attempt to remove the adapter instance, the adapter is already gone and we already have what we wanted. Reference: https://lists.zx2c4.com/pipermail/wireguard/2025-February/008762.html Signed-off-by: Simon Rozman

driver: fix spelling mistakes in comments

2022-05-23T13:57:34Z

Suggested-by: Dimitri Papadopoulos Signed-off-by: Jason A. Donenfeld

README: mention Windows 11

2022-04-22T16:22:47Z

Reported-by: Dimitri Papadopoulos Orfanos Signed-off-by: Simon Rozman

api: header: silence MSVC warnings for MSVC only

2021-12-03T08:17:19Z

MinGW ignores unknown `#pragma warning` lines, but displays a warning nevertheless. Signed-off-by: Simon Rozman

proj: stop building for arm32

2021-10-25T19:47:07Z

This does not remove 32-bit ARM compilation support out of the project yet. Shipping of 32-bit ARM drivers became a real challenge: - Microsoft changed policy to prohibit EV-signed drivers - Attestation signing is not supported for this platform - Setting up Windows 8 ARM HCK to get WHQL certification requires a lot of effort if doable in 2021 at all. Signed-off-by: Simon Rozman