glaurung windows driver findings

this page is a running catalog. the notepad write-up is the narrative — six months building a binary-analysis toolkit, sixty distracted minutes using it, and the discipline that keeps an llm honest against ground truth. that post is the method. this page is the findings: the windows kernel drivers glaurung has surfaced bugs in, one short entry each, kept in one place so the catalog stays discoverable instead of scattering into a post per bug.

each entry answers the same five questions: what the driver is, where the bug is, who can reach it, what the primitive actually buys an attacker, and how glaurung found it. and each entry ends the way the notepad post ended — with an honest read on whether microsoft should care, because half the value of this work is calibration: a finding you can defensibly decline is still a finding worth understanding.

why a catalog, not a post per bug

most of these bugs are not headline vulnerabilities. they are medium-severity reads and admin-gated denial-of-service — the normal output of pointing a careful tool at a large attack surface. a blog post each would over-state them and bury the ones that matter. a catalog states each at its true weight and lets the pattern across them carry the argument: the front-line, heavily-fuzzed user-mode parsers on a modern windows build are saturated, and the fresh yield is in the less-fuzzed kernel driver ioctl surfaces. that is a measurement, and it is more interesting than any single entry.

the method in one paragraph

the pipeline is calibrated, not open-ended — pointing an llm at a .sys and asking “find bugs” is a sub-one-percent true-positive regime, the same as it is for kernel source. so the order is fixed and the cheap, deterministic steps run first. scoop-check the driver against public cve history. scan the driver store for permissive device ACLs (a control device that grants Everyone read/write is the thing that turns a kernel bug into an unprivileged kernel bug). map the ioctl dispatch surface and decode the control codes. run structural bug-class scanners over the reachable handlers. only then does an llm read the lifted pseudo-c — and every claim it makes is re-grounded on capstone disassembly of the real bytes, never on the decompiler’s output, because the lifter is not magic and will hand a plausible-looking flags argument straight through. an adversarial pass then tries to refute each surviving candidate; a finding only counts if the refutation fails. where a bug can be driven without windows or hardware, a real-byte cpu emulation of the shipping driver closes the loop; where it needs a live kernel, a qemu vm with the driver loaded captures the actual bugcheck.

that refute-by-default step is load-bearing. the ndfltr entry below shipped with three candidate sites; one of them — the one that looked most exploitable — was a false positive that only fell apart when the validate and use sites were forced to run on a single buffer in one emulation trace. catching that before disclosure is the whole point.

findings

both were reported to microsoft through the MSRC researcher portal under coordinated disclosure, and microsoft assessed that neither meets their bar for servicing. that is the correct outcome for both, and the per-finding pages explain why in detail. the short version:

• ndkping is an administrator-to-kernel denial of service. under microsoft’s security servicing criteria the administrator-to-kernel transition is not a defended security boundary — an admin can load a driver and bugcheck the box at will, so a driver that lets them do it via an ioctl is not crossing a boundary that microsoft commits to defend. the bug is real and reproduces a clean blue-screen every time; it is simply on the wrong side of the boundary line.
• ndfltr is an unprivileged kernel read, which sounds more serious, but it only exists on hosts that have an RDMA NIC and an active NetworkDirect provider stack — storage-spaces-direct and azure-local territory, not a default desktop or server — and the demonstrated primitive is a wild out-of-bounds read whose reliable outcome is a crash, not a controlled information leak. narrow exposure plus a denial-of-service floor is a defensible decline.

publishing declined findings is deliberate. the notepad post made the case: concluding that microsoft should not fix something is as much a part of the work as finding it, and saying so in public is how you avoid training maintainers to discount your reports. the catalog will grow as the campaign produces more; entries that do get serviced will carry a CVE.

see also

• reading all of notepad.exe with an llm — the method, worked end to end on a shipping binary.
• ioctlance: windows driver vulnerability detection — the symbolic-execution tool that sits alongside glaurung for the same surface.