CVE-2024-45056

What it actually does

LLVM optimization incorrectly zero-extends a 64-bit mask instead of sign-extending to 256 bits on EraVM, emitting rotl 2^64-1,x instead of the expected roti 2^256-1,x for the pattern (xor (shl 1, x), -1).

Why it matters to the business

Developers using affected compiler versions risk deploying contracts with incorrect bitwise behavior on ZKsync EraVM; although no contracts were impacted at disclosure, all contracts must still be recompiled and redeployed after upgrade.

How an attack unfolds

An attacker compiles Solidity source containing the specific shift-xor pattern with an affected zksolc version; the resulting contract bytecode contains the wrong rotation constant and may produce incorrect results when executed on EraVM.

How to fix it

Upgrade matter-labs/era-compiler-solidity to commit 055ec47015e3b40cf821ac6e6aeb781f8094d167 (version 1.5.3) or later; recompile all contracts with the fixed compiler and redeploy them. No workarounds exist.

How to confirm the fix worked

Verify compiler binary reports version 1.5.3 or later; recompile a test contract containing the shift-xor pattern and inspect generated EraVM bytecode for the correct 256-bit rotation constant.

Typical attack path

1. Locate or develop Solidity code containing (xor (shl 1, x), -1) or equivalent
2. Compile with vulnerable zksolc/LLVM version under optimization
3. Deploy resulting contract to ZKsync EraVM
4. Trigger execution paths that exercise the faulty rotation

How to detect it

Search build logs and artifact repositories for zksolc versions prior to 1.5.3; inspect deployed contract bytecode for rotation operations using a 64-bit mask value instead of a full 256-bit mask.

What your security team should do

• Immediately upgrade all build pipelines to the fixed compiler version
• Recompile and redeploy every existing contract
• Add compiler version checks to CI/CD pipelines
• Monitor downstream dependents for continued use of pre-1.5.3 builds