Leaderboard

This version solved my issues, thanks.

Hello AirVPN Support and Development Team, I am writing to report a stability issue regarding a non-deterministic Blue Screen of Death (BSOD) with error code **0x3B (SYSTEM_SERVICE_EXCEPTION)** triggered when disconnecting from a WireGuard tunnel via the Eddie client. Because this crash happens intermittently during the teardown sequence, it strongly indicates a **Race Condition** or **Use-After-Free (UAF)** vulnerability inside the `wireguard.sys` driver wrapper, where memory buffers are accessed after being invalidated by the NDIS subsystem. **System Environment** * **OS:** Windows 10 IoT Enterprise LTSC 2021 (64-bit) * **Build Number:** 19044.7725 * **Eddie Version:** Any version utilizing WireGuard 1.0.0.0 * **WireGuard Driver Version:** WireGuard 1.0.0.0 **Bug Check Details & Stack Trace Summary** * **Bug Check Code:** 0x3B (`SYSTEM_SERVICE_EXCEPTION`) * **Exception Code:** 0xC0000005 (`EXCEPTION_ACCESS_VIOLATION`) * **Faulting Address:** `0xfffff8004f01111e` (Inside `ndis.sys`) * **Trigger Event:** Disconnecting from the WireGuard tunnel using Eddie. * **Key Stack Frames:** Crash manifests inside `ndis!ndisDeviceControlHandler` triggered by concurrent execution paths originating from `wireguard.sys+0x13b02` and `wireguard.sys+0x13844` during an IOCTL-driven shutdown. **Technical Analysis (Race Condition Hypothesis)** The crash signature and call stack point to a synchronization gap during the driver's teardown phase: 1. **Teardown Initiation:** Eddie issues an IOCTL call to halt the adapter. 2. **Memory Invalidation:** NDIS begins freeing `NDIS_MINIPORT_BLOCK` structures and associated packet buffers. 3. **Concurrent Access:** A pending network interrupt or timer event inside `wireguard.sys` simultaneously attempts to process packets using stale pointers. 4. **Violation:** The driver dereferences the invalidated memory, throwing an access violation within `ndis.sys`. **Reproduction Steps** 1. Launch Eddie and connect to any WireGuard endpoint. 2. Maintain the connection for an arbitrary duration. 3. Click **Disconnect**. 4. **Result:** The client intermittently crashes with BSOD 0x3B instead of executing a clean disconnect. The failure is purely stochastic and independent of network traffic load. **Troubleshooting Performed** * Fast Startup: Disabled. * Clean Install: Performed complete purges of Eddie and residual `wireguard.sys` drivers, followed by clean reinstalls. The issue persists. * Traffic Load: Tested under both idle and high-throughput states; failures occur uniformly, confirming a state-dependent synchronization bug rather than a load-dependent fault. **Impact & Request** This issue undermines system stability on Windows 10 IoT LTSC environments. Since the official WireGuard for Windows client utilizes `Wintun.sys` (which manages adapter concurrency and teardown safely in user-space/TUN architecture), the legacy `wireguard.sys` wrapper appears to lack robust reference counting or synchronization primitives (such as proper spinlock implementation) during NDIS miniport halts. Could you please clarify: * Are you aware of this specific race condition in `wireguard.sys`, and is there an updated build or fix available? * Are there plans to transition Eddie toward native `Wintun.sys` utilization to bypass these kernel-level concurrency constraints? Thank you for your time and assistance in analyzing this behavior. A full kernel memory dump (`MEMORY.DMP`) is attached to this message. 091326-9562-01.dmp