What the developer wrote
Authored by Ondřej Vejpustek
fix(core/embed): fix variable name
[no changelog]
What changed, and why it matters
This commit fixes a typo in the code that manages the Optiga secure chip's metadata. The code was writing a value to the wrong variable name (`metadata_locked` instead of `metadata`). Because the intended `metadata` structure was not fully initialized, the device might have compared stored secure-chip settings against an incomplete or incorrect expected value. In the worst case this could affect whether the device correctly detects that the Optiga chip is configured, which is part of the hardware-security boundary protecting secrets. The change is a one-line variable-name correction and is marked [no changelog], so the vendor does not describe it as a security fix.
Review the full context of `optiga_is_configured()` and its callers to confirm whether the uninitialized/mismatched `metadata.lcso` could lead to incorrect secure-element state decisions. If this code path is reachable during device boot or factory setup, consider whether a security advisory or additional hardening (e.g., static analysis for unused-variable warnings) is warranted. Users on production firmware should ensure they are on a version containing this fix.
Security signals we found
Incorrect variable used in security-critical metadata initialization
Lifecycle state (LCSO) assignment target mismatch in production build
Secure-element configuration check depends on the corrected value
No changelog entry provided by vendor
Evidence from the diff
In core/embed/sec/optiga/optiga.c, optiga_is_configured() builds an expected OptigaMetadata metadata structure and then reads the actual metadata from OID_PIN_SECRET into a separate metadata_stored structure. Under #if PRODUCTION, the code previously assigned metadata_locked.lcso = OPTIGA_META_LCS_OPERATIONAL;. The local variable metadata_locked is not used elsewhere in the visible function, so the intended target was almost certainly metadata.lcso. Without this assignment, metadata.lcso remains whatever value the struct was initialized to (likely 0 / OPTIGA_META_LCS_NEW from the preceding memset, based on typical patterns). The subsequent comparison between metadata and metadata_stored would then expect a different lifecycle state than operational. This could cause optiga_is_configured() to return false when the chip is actually operational, or, depending on how callers react, could influence initialization/locking behavior of the secure element.
Changed components
core/embed/sec/optiga/optiga.cOptiga secure-element metadata handlingoptiga_is_configured() functionProduction builds using PRODUCTION macroInspect captured patch +1 / −1
diff --git a/core/embed/sec/optiga/optiga.c b/core/embed/sec/optiga/optiga.c
index 08677138c..7e0260c7b 100644
--- a/core/embed/sec/optiga/optiga.c
+++ b/core/embed/sec/optiga/optiga.c
@@ -368,7 +368,7 @@ static bool optiga_is_configured() {
metadata.execute = OPTIGA_META_ACCESS_ALWAYS;
metadata.data_type = TYPE_AUTOREF;
#if PRODUCTION
- metadata_locked.lcso = OPTIGA_META_LCS_OPERATIONAL;
+ metadata.lcso = OPTIGA_META_LCS_OPERATIONAL;
#endif
if (!read_metadata(OID_PIN_SECRET, &metadata_stored)) {
Why this scored 57/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.