Hacking Tools

Program Exposes Unsound And Incomplete Behavior In Compiler

The provided program highlights critical issues within the compiler, exposing both soundness and completeness violations.

These bugs manifest in unexpected behavior during execution and compiler crashes, triggered by seemingly innocuous code changes. This article explores the problem, its symptoms, and implications.

Program Behavior

The program is written in Noir and aims to compute a value, out0, which should consistently return Field(0) regardless of input. However, the actual behavior deviates from expectations:

  1. If executed as-is, the program returns Field(-1) instead of the expected Field(0).
  2. Removing empty else blocks causes a compiler panic with an internal error.
  3. Semantic-equivalent changes to the code—such as modifying conditional checks or rearranging variable declarations—alter the output to the correct Field(0).

The program reveals two types of bugs:

  1. Compiler Completeness Issue: Removing any empty else block results in a crash during execution (nargo execute).
    • The error message indicates an unreachable code path in the compiler’s SSA optimization phase (inlining.rs:504). This suggests that the compiler fails to handle certain edge cases during instruction inlining.
  2. Soundness Violation: The program’s output changes unexpectedly based on minor structural modifications. For example:
    • Replacing (out0 == out0) with (in0 == in0) or (tmp1 == tmp1) fixes the output.
    • Moving let mut tmp2 : Field = 0; to the top of the program also resolves the issue.
    • Removing certain conditions or assertions causes unpredictable behavior.

Uncommenting assertions like assert(out0 == 0, "completeness violation"); or assert(out0 != 0, "soundness violation"); further exposes these problems.

The first assertion fails despite being logically correct, while the second passes erroneously, demonstrating unsound evaluation.

These bugs undermine trust in the compiler’s reliability for critical applications. To reproduce:

  • Create a new Noir project (nargo init).
  • Replace src/main.nr with the provided code.
  • Add a Prover.toml file specifying in0 = "1".
  • Run nargo execute.

Currently, there is no known workaround for these issues. Developers must avoid triggering problematic conditions until a fix is implemented.

This program demonstrates severe flaws in the compiler’s handling of edge cases, affecting both correctness and stability. Addressing these issues is crucial for ensuring reliable execution and soundness in Noir-based projects.

Varshini

Varshini is a Cyber Security expert in Threat Analysis, Vulnerability Assessment, and Research. Passionate about staying ahead of emerging Threats and Technologies.

Recent Posts

Playwright-MCP : A Powerful Tool For Browser Automation

Playwright-MCP (Model Context Protocol) is a cutting-edge tool designed to bridge the gap between AI…

2 weeks ago

JBDev : A Tool For Jailbreak And TrollStore Development

JBDev is a specialized development tool designed to streamline the creation and debugging of jailbreak…

2 weeks ago

Kereva LLM Code Scanner : A Revolutionary Tool For Python Applications Using LLMs

The Kereva LLM Code Scanner is an innovative static analysis tool tailored for Python applications…

2 weeks ago

Nuclei-Templates-Labs : A Hands-On Security Testing Playground

Nuclei-Templates-Labs is a dynamic and comprehensive repository designed for security researchers, learners, and organizations to…

2 weeks ago

SSH-Stealer : The Stealthy Threat Of Advanced Credential Theft

SSH-Stealer and RunAs-Stealer are malicious tools designed to stealthily harvest SSH credentials, enabling attackers to…

2 weeks ago

ollvm-unflattener : A Tool For Reversing Control Flow Flattening In OLLVM

Control flow flattening is a common obfuscation technique used by OLLVM (Obfuscator-LLVM) to transform executable…

2 weeks ago