QNSQY memory-safety audit summary  (sanitized)

Language: Rust. The memory-corruption vulnerability class (buffer overflow, use-after-free,
double-free, etc.) is excluded by construction from safe Rust code.

unsafe blocks audited: 189  (all first-party unsafe blocks, reviewed one by one for aliasing,
  lifetime, bounds, alignment, and FFI-contract correctness).
miri (Rust undefined-behavior checker): clean on the pure-Rust safe-math / overflow-protection
  module. Paths that call into C cryptography are outside miri's reach and were not covered.
AddressSanitizer (covers the C-FFI paths miri cannot reach): an ASan-instrumented build
  executed 13,248 NIST ACVP vectors across 32 algorithm modules (ML-KEM, ML-DSA, SLH-DSA,
  AES-GCM, EdDSA, SHA-2/3) with ZERO AddressSanitizer errors and zero test failures
  (run time-capped before the remaining modules; 2026-06-15).

Findings (severity counts only; exploit-level detail deliberately withheld):
  HIGH-risk soundness / UB items : 10
  MEDIUM-risk items             : 26
  Representative categories (no source locations disclosed):
    - aliasing-pattern UB in a shared-secret zeroization routine (shipping path)
    - layout/repr assumption in the HSM integration path (feature not yet enabled)
    - read-extent hardening in the binary integrity self-check
    - error-path zeroization and resource-cleanup items

Status: none has been demonstrated as a working memory-corruption exploit on the shipping
  Linux build; the more serious out-of-bounds cases are confined to the HSM feature that is
  not yet enabled. Priority shipping-path items are now remediated (below); the rest are tracked.

Remediation status (2026-06-15):
  - aliasing-pattern UB in the shared-secret zeroization (shipping path): FIXED and
    compile-verified. The raw pointer is now derived from an exclusive &mut to an owned copy,
    so no shared/mutable aliasing exists.
  - read-extent hardening in the binary integrity self-check: FIXED and compile-verified.
    The monitored and monitoring functions are pinned with #[inline(never)] so their addresses
    are stable and the bounded read no longer relies on LTO behavior.
  - layout/repr assumption in the HSM integration path: forward handle conversion rewritten to
    be layout-agnostic (no unsafe, no repr assumption). The reverse conversion retains one
    unsafe write only because the upstream PKCS#11 binding (cryptoki 0.10) exposes no public
    constructor; this path is behind the not-yet-enabled HSM feature and is documented and
    tracked for the v7.3 HSM milestone.
  - remaining error-path zeroization / resource-cleanup and a Windows protect-size case: tracked.
  None of the fixes changed cryptographic behavior; the production build compiles clean
  (0 errors, 0 warnings).

Exact file/line locations, proof-of-concept inputs, and the full findings register are
withheld as security-sensitive while remediation is in progress.