Providing the DataOffset member of the NBL allocation function or
setting that member in the NB header indicates to NDIS not only that the
data starts at that offset, but that there's that amount of space
*available for it to use as it wants* before that offset. This meant
that NDIS was allowed to scribble data before the packet.
This was bounded by the size of the ring, so there was never any risk of
memory corruption, and since the ring is shared by userspace as well as
the rest of the kernel, we've always taken care of reading from it
closely, checking all values, and erroring out on corruption of the
ring. So, if NDIS wrote before the first packet, this would wind up
corrupting the RingTail and Alertable fields of the ring. The receiver
thread would then notice this, error out, and set the RingHead to
MAXULONG on its way out the door, so that userspace can detect it. And
indeed wintun.dll then started returning EOF from its write function.
Mostly this was not an issue, because we're not expecting for data to be
pushed on the head of a packet on ingress. But WSL2's Hyper-V driver is
actually pushing an ethernet header onto the front of the packet before
passing it off to Linux. Practically speaking, this manifested itself in
the RingTail and Alertable fields having Linux's MAC address! And then
the adapter would be EOF'd. This was reported as happening after WSL2
sends the *first* packet, but not others, which makes sense, because it
has to be at the beginning in order to corrupt those fields.
This fixes the problem by simply using a new MDL for the span we want,
instead of using the misunderstood DataOffset field. In order to not
need to keep track of memory allocations, we allocate the MDL as part of
the NBL's context area. And in order to avoid additional mappings, we
use IoBuildPartialMdl, which returns an MDL_PARTIAL, which does not have
an additional mapping that needs to be freed or unmapped.
After making this change, WSL2 no longer appears to halt the adapter,
and all works well.
Fixes: be8d2cb ("Avoid allocating second MDL")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Otherwise the build fails at odd hours of the day.
Signed-off-by: Stefan Rinkes <stefan.rinkes@gmail.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
RtlGenRandom forwards to cryptbase.dll, which is not in KnownDlls.
Therefore it's not a good idea to link to advapi32.dll at link time. How
many other gotchas of unusual forwarded functions are there? I don't
really want to find out. Therefore, delay load everything else.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This doesn't change much, but it does make it mildly more convenient
plop this into mixed-use codebases.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
There seems to be a race in the TCP/IP adapter registry key. Sometimes,
the adapter TCP/IP key is created, but setting the value
EnableDeadGWDetect fails with ERROR_TRANSACTION_NOT_ACTIVE.
Signed-off-by: Simon Rozman <simon@rozman.si>
In theory, the compiler could reload PacketSize after the bounds check
but before it's passed to NdisAllocateNetBufferAndNetBufferList. In
practice, it's not actually doing that, but better safe than sorry.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This seems to reset a number of device properties, and our update flow
seems to update old adapters without needing to call this.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This prevents us from racing with driver deletion. Mutexes are
recursive, so we shouldn't deadlock if called from Enum.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The LastError was overridden by the stdout reader thread exit code
masking the true reason why ExecuteRunDll32() failed and even worse: as
the thread exited gracefully, the true reason was overridden by
ERROR_SUCCESS and returning TRUE (success).
Signed-off-by: Simon Rozman <simon@rozman.si>
This makes the API parallel:
Wintun*Allocate*SendPacket -> WintunSendPacket
WintunReceivePacket -> Wintun*Release*ReceivePacket
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The additional build steps performed are now attached to the build
process using BeforeTargets/AfterTargets.
Signed-off-by: Simon Rozman <simon@rozman.si>
This makes our intentions a lot more clear, and in case we ever add
other version functions, makes the forward path simpler.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
