Updated
A real bug. An incorrect claim of novelty.
A driver reproduced a known vulnerability, but our pipeline called it new. The mistake was treating an unfamiliar file hash as evidence of an unfamiliar bug.
Our pipeline reproduced a vulnerability in a Windows driver and labelled it new. The reproduction was useful. The novelty claim was wrong.
The issue was already recorded as CVE-2024-33228. What looked like a discovery was a rediscovery.
The failure came from asking a file-hash lookup to answer a question about vulnerability history.
What the machine had established
The investigation began with a stripped driver binary. The analysis located a device-control handler and traced a path to a physical-memory mapping operation.
In the instrumented test, the pipeline inspected the operation’s operands and compared returned data with the corresponding memory. That evidence supported the reported memory-access behavior under the test conditions.
It didn’t establish that the behavior was unknown. It also wasn’t, by itself, proof of an end-to-end privilege-escalation exploit. Those are separate claims requiring separate evidence.
Where the novelty check failed
The driver wasn’t present in the known-vulnerable-driver catalogue under the hash we supplied. The pipeline treated that absence as evidence of a new vulnerability.
A hash identifies one file. Rebuilding a vulnerable driver can change its hash without changing the vulnerable code. Signing, packaging, or other binary changes can produce the same mismatch.
The lookup had answered, “Have we catalogued these exact bytes?” We had interpreted the answer as, “Has anyone reported this defect?”
That is why a reproduction and a novelty search have to remain separate parts of a research workflow.
A better way to search the prior record
The useful search terms describe the defect: the product, affected version, handler or function, operation, and weakness class. They can connect two reports whose files have different hashes.
Public advisories and vendor notices provide the first comparison. Technical descriptions help when naming differs between reports. A broader search can fill gaps for drivers and firmware whose records don’t map neatly onto package names.
An internal comparison matters too. The same sink or root cause may have appeared in an earlier investigation under a different target name. Matching technical characteristics is more useful than comparing the wording of two titles.
These checks produce evidence for a decision. They don’t make the public record complete.
What a clean search means
“No matching report found” is a bounded result. It should carry the sources searched and the date of the search. It cannot establish that no report exists, that a vendor hasn’t fixed the issue privately, or that another researcher hasn’t submitted it.
Likewise, a possible match should remain inspectable. Similar descriptions can refer to different bugs; different descriptions can refer to the same one. Automatically deleting candidates on a loose match would exchange one error for another.
Our correction was to treat novelty as a question still requiring review, even when reproduction succeeds. The evidence record needs to distinguish what ran on the machine from what we learned about prior work.
The driver-analysis article explains the reproduction process. This case explains its limit: proving the behavior never established that we were first.