commit 88bbfee169987674c29d4398ff6630ac2008022f
Author: NJL <23+njl@noreply.git.churchofmalware.org>
Date:   Mon Jul 6 18:50:00 2026 +0000

    Add README.me

diff --git a/README.me b/README.me
new file mode 100644
index 0000000..a20df81
--- /dev/null
+++ b/README.me
@@ -0,0 +1,30 @@
+# What day-zero dug up in tcpip.sys
+
+Windows TCP/IP driver, 8,421 functions, no symbols. These are leads, not
+confirmed bugs — spots worth opening in Ghidra, not proof of anything.
+
+A length going into `NdisGetDataBuffer`:
+
+```
+len = ((arg2 & 0xf) << 2) - 20
+```
+
+Low nibble times 4, minus 20 — a header-length field in 4-byte words with a
+20-byte header subtracted off. Nibble under 5 and it underflows to ~4GB.
+
+A length walked through four functions, none of them bounding it, from a network
+entry point down into a packet parser:
+
+```
+0x1400557d0 -> 0x140053d04 -> 0x14006323c -> 0x140061850 -> NdisGetDataBuffer
+```
+
+Every hop assumes someone else checked it.
+
+A handful of WFP functions (`WfpBufferCopy`,
+`WfpHandOffTupleStateToTemporaryAleEntry`) hand an unchecked value straight to
+`ExAllocatePool2` as the allocation size. One computes it as `(input << 4) + 0x2e`
+— multiply attacker input by 16, allocate that.
+
+And the spots that *do* bound the same `(nibble << 2)` length with a proper
+`<= 0x14` check — flagged as fine, not as findings.