wintun/driver, 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

driver: fix spelling mistakes in comments

2022-05-23T13:57:34Z

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

driver: address Code Analysis warning

2021-10-17T11:25:14Z

In this case, we're referencing objects by handle for closing user space handles. Should be UserMode, not Irp->RequestorMode as C28126 suggests. Signed-off-by: Simon Rozman

driver: allow ring registration from kernel

2021-10-17T11:21:38Z

Signed-off-by: Simon Rozman

driver: address Code Analysis warnings

2021-10-17T11:11:42Z

Signed-off-by: Simon Rozman

driver: automatically close long-lived handle

2021-10-12T18:55:24Z

There's only one handle that's likely to be open in a long lived way: the tun registration handle. So we can force that closed automatically when the device is about to close, if it's been improperly left open. Other handles will indeed hold up closing, but if those exist, they're a sign of a larger bug elsewhere that should be addressed. On the other hand, tun registration handles might legitimately be open during driver upgrades. This also saves us the trouble of dereferencing a freed FileObject as in the general case. Signed-off-by: Jason A. Donenfeld

api: rewrite based on SwDevice

2021-10-12T18:54:20Z

Signed-off-by: Jason A. Donenfeld