CVE-2026-41197
Essential information
- Published
- 23/04/2026 02:16
- Modified
- 24/04/2026 14:50
- Author
- —
- Creator
- —
- CVSS
- 9.3 CRITICAL (v3) 9.3 CRITICAL (v4.0)
- CISA KEV
- No
- CWE
- —
- CVSS vector
-
—
—
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
CVSS metrics
- Access vector
- —
- Access complexity
- —
- Authentication
- —
- Confidentiality impact
- —
- Integrity impact
- —
- Availability impact
- —
- Exploitability
- —
- Remediation level
- —
- Report confidence
- —
- Temporal score
- —
- Attack vector
- —
- Attack complexity
- —
- Privileges required
- —
- User interaction
- —
- Scope
- —
- Confidentiality impact
- —
- Integrity impact
- —
- Availability impact
- —
- Exploit code maturity
- —
- Remediation level
- —
- Report confidence
- —
- Temporal score
- —
- Attack vector
- NETWORK
- Attack complexity
- LOW
- Attack requirements
- NONE
- Privileges required
- NONE
- User interaction
- NONE
- Confidentiality (V)
- HIGH
- Confidentiality (S)
- NONE
- Integrity (V)
- HIGH
- Integrity (S)
- NONE
- Availability (V)
- HIGH
- Availability (S)
- NONE
- Exploit maturity
- NOT_DEFINED
Description
Noir is a Domain Specific Language for SNARK proving systems that is designed to use any ACIR compatible proving system, and Brillig is the bytecode ACIR uses for non-determinism. Noir programs can invoke external functions through foreign calls. When compiling to Brillig bytecode, the SSA instructions are processed block-by-block in `BrilligBlock::compile_block()`. When the compiler encounters an `Instruction::Call` with a `Value::ForeignFunction` target, it invokes `codegen_call()` in `brillig_call/code_gen_call.rs`, which dispatches to `convert_ssa_foreign_call()`. Before emitting the foreign call opcode, the compiler must pre-allocate memory for any array results the call will return. This happens through `allocate_external_call_results()`, which iterates over the result types. For `Type::Array` results, it delegates to `allocate_foreign_call_result_array()` to recursively allocate memory on the heap for nested arrays. The `BrilligArray` struct is the internal representation of a Noir array in Brillig IR. Its `size` field represents the semi-flattened size, the total number of memory slots the array occupies, accounting for the fact that composite types like tuples consume multiple slots per element. This size is computed by `compute_array_length()` in `brillig_block_variables.rs`. For the outer array, `allocate_external_call_results()` correctly uses `define_variable()`, which internally calls `allocate_value_with_type()`. This function applies the formula above, producing the correct semi-flattened size. However, for nested arrays, `allocate_foreign_call_result_array()` contains a bug. The pattern `Type::Array(_, nested_size)` discards the inner types with `_` and uses only `nested_size`, the semantic length of the nested array (the number of logical elements), not the semi-flattened size. For simple element types this works correctly, but for composite element types it under-allocates. Foreign calls returning nested arrays of tuples or other composite types corrupt the Brillig VM heap. Version 1.0.0-beta.19 fixes this issue.
NVD status
- Status
- Awaiting Analysis — CVE has been recently published to the CVE List and has been received by the NVD.
- Source
- [email protected]
- NVD
- View on NVD
Affected products (CPE)
| Product | CPE |
|---|---|
| noir / noir | cpe:2.3:a:noir:noir:1.0.0-beta.19:*:*:*:*:*:*:* |
| noir / brillig | cpe:2.3:a:noir:brillig:*:*:*:*:*:*:*:* |