public inbox for wireguard@lists.zx2c4.com
 help / color / mirror / Atom feed
From: odedkatz <katz.oded@gmail.com>
To: wireguard@lists.zx2c4.com
Cc: odedk@twingate.com, odedkatz <katz.oded@gmail.com>
Subject: [PATCH 0/1] This PR fixes a critical race condition in the Wintun driver that causes ring buffer overruns
Date: Thu, 19 Feb 2026 11:32:54 -0800	[thread overview]
Message-ID: <20260219193255.14334-1-katz.oded@gmail.com> (raw)

** Description **
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.

** Changes **
Extended the critical section in TunSendNetBufferLists by moving spinlock acquisition before reading Ring->Head, ensuring atomic read-modify-write operations on the ring buffer state
Fixed the lock release timing in TunReturnNetBufferLists to occur after updating Ring->Head, ensuring consistency between the active NBL list and ring buffer head pointer

** History **
the issue was reported to wireguard

```
We were trying to integrate `wintun` into our product and while
testing we found an issue with upload of high UDP throughput on
multiple sockets. initially we thought it may be related to our
integration. but we managed to find the same issue in your example
code.we tried to do some debugging on the example, but it seems like
the corruption is on the driver side.
the way to reproduce this issue- run the example
- run the `send_udp.py` (the attached python script) on 2 different
command terminals
   - `send_udp.py 10.6.7.8 5201 1450`
   - `send_udp.py 10.6.7.8 5201 1400`after some time the
`WintunReceivePacket` returns NULL and `GetLastError()` return 13
(`ERROR_INVALID_DATA`)
many thanks,
```

a fix was provided by wireguard with [this commit](https://git.zx2c4.com/wintun/commit/driver/wintun.c?id=8814f660310c30a9297fc640c844c4ab6f27e5d7), but it didn't solve the issue.


odedkatz (1):
  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.

 driver/wintun.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

-- 
2.43.0


             reply	other threads:[~2026-02-19 19:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-19 19:32 odedkatz [this message]
2026-02-19 19:32 ` [PATCH 1/1] 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 odedkatz
2026-02-20  7:28   ` Simon Rozman
2026-02-20 16:55     ` Oded Katz
2026-02-27 21:28       ` Oded Katz
2026-02-27 22:03         ` Simon Rozman
2026-02-28  1:12           ` Oded Katz
2026-03-11 23:35     ` Oded Katz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260219193255.14334-1-katz.oded@gmail.com \
    --to=katz.oded@gmail.com \
    --cc=odedk@twingate.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox