Report suspected vulnerabilities privately through GitHub private vulnerability reporting. Do not put exploitable details, private inputs, credentials, or crash dumps containing application data in public issues.
The latest published release is supported for security fixes. Older releases may receive fixes at maintainer discretion; consumers should upgrade to the latest compatible release. Maintainers will coordinate disclosure and publish advisories for confirmed vulnerabilities. This project does not promise a fixed response deadline.
Include the affected version/commit, platform and toolchain, a minimal reproduction, expected versus observed behavior, and the relevant ownership or ABI contract. Sanitizer diagnostics and reduced fuzz inputs are particularly useful. State whether the failure is in the generator, LLVM object application, native value producer/consumer, or generated bindings.
Generated optimizer and native-leaf contracts are assertions supplied by the application author. Myna validates their consistency, but cannot prove that arbitrary native code obeys them. Borrowed data must outlive every consumer, custom allocators must satisfy their contracts, and direct SVM memory views require valid addresses and lengths. Incorrect application contracts can cause memory unsafety; validation bypasses or unsafe behavior under valid contracts are in scope for private reports.
See native validation for sanitizer/fuzzer commands and their limits. Native-library instrumentation does not imply that SVM's managed heap is instrumented.
An administrator receiving a private report assigns an owner and acknowledges the report, requesting a reduced reproduction if necessary. The owner reproduces it with the affected revision and pinned toolchain, identifies the trust boundary and supported contracts involved, and assesses severity and affected versions. Keep exploit details and customer data in the private advisory while a fix is developed. Escalate an unattended report to another administrator; prioritize confirmed critical vulnerabilities immediately.
Develop a regression test and fix privately where disclosure would endanger users. Run the relevant sanitizers and integration tests, obtain another maintainer's review, and prepare a patched release through the normal release process. Coordinate publication with the reporter, request a CVE when appropriate, and publish affected versions, impact, mitigation, and upgrade instructions in the advisory and release notes. Credit the reporter unless they request anonymity. Record the dates of receipt, acknowledgment, confirmation, fix, and disclosure so response times can be audited. Never close a confirmed exploitable finding solely because a scanner stopped reporting it.
Myna is a local compiler and FFI SDK, not a sandbox for hostile native code. Its assets are generated binding correctness, memory ownership, caller data, and build artifact integrity. Potential attackers can supply malformed seam descriptions, LLVM objects/archives, and value tapes. Applications may also accidentally supply contradictory ABI facts or invalid lifetimes. A compromised compiler, runtime, application native library, or build host is outside the protection Myna can provide. Run generation and object application on untrusted inputs in an isolated, resource-limited build environment; parsing arbitrary LLVM input is not a resource-exhaustion guarantee.
The principal trust boundaries are:
- Seam text to the typed model and approved optimizer contracts. Parsing and validation reject unknown types, inconsistent signatures, unsupported combinations, and unjustified optimizer facts. Explicit relaxed mode omits unapproved facts rather than treating them as proven. See DSL rules and
src/main/java/dev/elide/myna/validate/Validator.java. - Contract metadata to LLVM objects. The applicator verifies the SHA-256 fingerprint, target/signature compatibility and LLVM validity before writing the result. Malformed archive and FatLTO inputs have regression tests in
tests/llvm_integration.py. A fingerprint detects inconsistent contracts; it does not authenticate an untrusted producer. - Managed code to native addresses, allocations, and callbacks. Ownership rules and adapter contracts define lifetimes, thread restrictions, exactly-once destruction, and callback error handling. FFM borrows validate segment properties; raw-pointer APIs deliberately retain the application's responsibility for valid memory. Native-leaf calls require bounded, nonblocking, non-reentrant implementations. Myna cannot prove that arbitrary native code meets a declared contract.
- Native value producers to consumers. Value ABI v3 specifies tags, offsets, bounds, UTF-8, exact number tokens, allocator ownership and poisoned-builder recovery. Tests cover malformed values, allocation failures and configured resource limits. Caller-supplied borrowed regions must remain valid; zero-copy traversal does not authorize dereferencing arbitrary attacker-chosen addresses.
- Source to distributed artifacts. Pinned tools, checksums, scoped CI permissions and signed release provenance constrain supply-chain substitution. Consumers must verify the artifact digest and intended workflow/source identity. Provenance is evidence of how bytes were built, not a proof that source code is safe.
The design minimizes shared state and implicit work: direct traversal does not parse JSON, materialize objects, or silently transfer allocation ownership. Validation uses accepted types, ranges, and contracts rather than lists of known bad inputs. Unsafe operations are concentrated at documented FFI boundaries. Runtime symbol lookup keeps process addresses out of the image heap. Explicit non-leaf declarations and error paths fail closed when a proposed contract is unsupported. These choices apply simplicity, fail-safe defaults, least privilege, complete validation at the relevant boundary, and open design; there is no hidden security algorithm.
Evidence is provided by production coverage gates, malformed-input and ownership regression tests, real SVM/JVM adapter execution, static analysis, and ASan/UBSan/LSan/TSan workloads with expected-failure canaries. See validation commands and limitations. These counter bounds errors, overflow, use-after-free, allocator mismatch, data races, and invalid ABI lowering under the documented contracts. They do not prove absence of defects, instrument every managed-runtime operation, or make unchecked native pointers safe. New findings must refine this argument and its tests.