{"id":"CVE-2026-41197","state":"PUBLISHED","title":"Brillig: Heap corruption in foreign call results with nested tuple arrays","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.","publishedAt":"2026-04-23T00:35:37.842Z","updatedAt":"2026-04-25T03:55:38.608Z","severity":{"score":9.3,"label":"Critical","version":"4.0","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","source":"GitHub_M"},"assigner":"GitHub_M","products":["noir-lang noir"],"affected":[{"vendor":"noir-lang","product":"noir","versions":[{"version":"< 1.0.0-beta.19","status":"affected"}]}],"references":["https://github.com/noir-lang/noir/security/advisories/GHSA-jj7c-x25r-r8r3","https://github.com/noir-lang/noir/releases/tag/v1.0.0-beta.19"],"weaknesses":["CWE-131"],"ingestedAt":"2026-10-29T20:11:57.932Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2026/41xxx/CVE-2026-41197.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-41197","state":"PUBLISHED","datePublished":"2026-04-23T00:35:37.842Z","dateUpdated":"2026-04-25T03:55:38.608Z","assignerShortName":"GitHub_M","assignerOrgId":"a0819718-46f1-4df5-94e2-005712e83aaa","dateReserved":"2026-04-18T02:51:52.973Z"},"containers":{"cna":{"title":"Brillig: Heap corruption in foreign call results with nested tuple arrays","descriptions":[{"lang":"en","value":"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."}],"affected":[{"vendor":"noir-lang","product":"noir","versions":[{"version":"< 1.0.0-beta.19","status":"affected"}]}],"references":[{"url":"https://github.com/noir-lang/noir/security/advisories/GHSA-jj7c-x25r-r8r3","name":"https://github.com/noir-lang/noir/security/advisories/GHSA-jj7c-x25r-r8r3","tags":["x_refsource_CONFIRM"]},{"url":"https://github.com/noir-lang/noir/releases/tag/v1.0.0-beta.19","name":"https://github.com/noir-lang/noir/releases/tag/v1.0.0-beta.19","tags":["x_refsource_MISC"]}],"metrics":[{"cvssV4_0":{"attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","baseScore":9.3,"baseSeverity":"CRITICAL","vectorString":"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","version":"4.0"}}],"problemTypes":[{"descriptions":[{"cweId":"CWE-131","lang":"en","description":"CWE-131: Incorrect Calculation of Buffer Size","type":"CWE"}]}],"providerMetadata":{"shortName":"GitHub_M","orgId":"a0819718-46f1-4df5-94e2-005712e83aaa","dateUpdated":"2026-04-23T00:35:37.842Z"},"source":{"advisory":"GHSA-jj7c-x25r-r8r3","discovery":"UNKNOWN"}},"adp":[{"title":"CISA ADP Vulnrichment","metrics":[{"other":{"type":"ssvc","content":{"timestamp":"2026-04-24T00:00:00+00:00","options":[{"Exploitation":"none"},{"Automatable":"yes"},{"Technical Impact":"total"}],"role":"CISA Coordinator","version":"2.0.3","id":"CVE-2026-41197"}}}],"providerMetadata":{"shortName":"CISA-ADP","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","dateUpdated":"2026-04-25T03:55:38.608Z"}}]}}}