Skip to content

Conversation

@leodemoura
Copy link
Member

This PR fixes an adversarial soundness attack described in #8554. The attack exploits the fact that assert! no longer aborts execution, and that users can redirect error messages.
Another PR will implement the same fix for Expr.Data.

@leodemoura leodemoura added the changelog-compiler Compiler, runtime, and FFI label May 30, 2025
@leodemoura leodemoura added this pull request to the merge queue May 31, 2025
@github-actions github-actions bot added the toolchain-available A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN label May 31, 2025
@leanprover-community-bot
Copy link
Collaborator

Mathlib CI status (docs):

  • ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase ed4252f8c93f591ae753cc963cfd69657ebd3e6a --onto 72141b05fd9a3328c1e5d99211dc4da4495cbd42. You can force Mathlib CI using the force-mathlib-ci label. (2025-05-31 00:11:41)

Merged via the queue into master with commit 6940d2c May 31, 2025
17 of 18 checks passed
leodemoura added a commit that referenced this pull request May 31, 2025
This PR is similar to #8559, but for `Expr.mkData`
github-merge-queue bot pushed a commit that referenced this pull request May 31, 2025
…8560)

This PR is similar to #8559 but for `Expr.mkData`. This vulnerability
has not been exploited yet, but adversarial users may find a way.
let r : UInt64 := h.toUInt32.toUInt64 + hasMVar.toUInt64.shiftLeft 32 + hasParam.toUInt64.shiftLeft 33 + depth.toUInt64.shiftLeft 40
r
@[extern "lean_level_mk_data"]
opaque Level.mkData (h : UInt64) (depth : Nat := 0) (hasMVar hasParam : Bool := false) : Level.Data
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that it is still possible to prove that Level.Data is finite here, because it is not opaque type, and moreover Level.Data.depth returns a UInt32. If you are going to use this approach, please at least take the modification to lower the max bvar range to 2^20-2, so that it is at least possible to prove that there exists a sound implementation of the function which is indistinguishable from the real one without hitting a panic.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or alternatively, make Level.depth and Expr.looseBVarRange opaque, so that it cannot be seen that they are implemented by projecting out of a finite type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog-compiler Compiler, runtime, and FFI toolchain-available A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants