|
|
Two results now sit side by side: a mechanically verified count underflow that is not
reachable in the shipping build because its front half needs a larger payload than any
application delivers, and the absence of version enforcement, which lets an attacker choose
which build runs.
Unreachability is a property of one build's gates, so the question becomes precise: in
either older build, is the front half open? If it is, rollback plus the existing defect is
an exercisable primitive rather than a documented but unreachable one.
Both older bodies are plaintext by entropy so they are directly analyzable, and both are
committed with hashes in the manifest.
It is recorded as a lead rather than a result, with caveats stated: the defect shape exists
in every build so the back half is only presumably open and must be confirmed per image, a
string diff shows no added error messages so there is no cheap signal that a bounds fix
landed in the window, and each detector must rediscover a known defect in that specific
image before any negative from it is trusted.
|
