Triaged during the 7.14.2 residual pass and deferred out of 7.14.2 as low. Still present at release/7.14.2 head.
Evidence
lib/firmware/fsm.c:193 (static HDNode CONFIDENTIAL node;, no memzero anywhere in fsm.c); lib/firmware/u2f.c:503
Assessment
Still present. fsm.c gained 13 lines on this branch (the CHECK_NO_CEREMONY macro) and nothing else; grep -n memzero lib/firmware/fsm.c at HEAD still returns only the include at line 75, so the fully-derived HDNode at fsm.c:193 — chain code plus the 32-byte private key at the caller's path — is never zeroed. u2f.c:503 is likewise untouched. I confirmed session_clear_impl (storage.c:1411-1461) only clears SessionState.seed/passphrase/storageKey and Storage::sec, so neither auto-lock, ClearSession nor Initialize touches these statics.
Two corrections to the original writeup. First, crypto.c:278 is listed in the finding's files but is not part of the defect — that static is built by hdnode_from_xpub and holds only public material. Second, CONFIDENTIAL is not inert on hardware: CMakeLists.txt:88 expands it to __attribute__((section("confidential"))), and tools/bootloader/main.c:83 zeroes _confidential_start.._confidential_end at boot. That does NOT rescue this, though — those symbols are defined only in tools/bootloader/bootloader.ld, sized to the bootloader's own (much smaller) set of CONFIDENTIAL objects, while tools/firmware/keepkey.ld:23 declares the firmware's section with no start/end symbols and nothing zeroes it. So the firmware's node is not reliably cleared even by a warm reset into the bootloader.
I rate it low rather than the recorded medium because the exploitation link is missing under the stated threat model. A malicious USB host has no memory-read primitive: KK_DEBUG_LINK defaults OFF (CMakeLists.txt:21) and there is no MemoryRead/DebugLinkMemoryRead handler in lib/firmware at all. Turning this key material into disclosure needs either a separate memory-disclosure defect or chip-level SRAM readout with physical access to a locked device — the rubric's 'low' band. It is still a genuine break of the lock guarantee (a device the user believes is locked retains a spendable account key) and deserves an issue. File it as an extension of #399's scope, naming fsm.c:193 as the highest-traffic instance and u2f.c:503 alongside it; do not hold the tag for it.
Deferred because 7.14.2 is a minimal security release; this did not clear the bar for a late change. Filed so it is not lost.
Triaged during the 7.14.2 residual pass and deferred out of 7.14.2 as
low. Still present atrelease/7.14.2head.Evidence
lib/firmware/fsm.c:193 (
static HDNode CONFIDENTIAL node;, no memzero anywhere in fsm.c); lib/firmware/u2f.c:503Assessment
Still present. fsm.c gained 13 lines on this branch (the CHECK_NO_CEREMONY macro) and nothing else;
grep -n memzero lib/firmware/fsm.cat HEAD still returns only the include at line 75, so the fully-derived HDNode at fsm.c:193 — chain code plus the 32-byte private key at the caller's path — is never zeroed. u2f.c:503 is likewise untouched. I confirmed session_clear_impl (storage.c:1411-1461) only clears SessionState.seed/passphrase/storageKey and Storage::sec, so neither auto-lock, ClearSession nor Initialize touches these statics.Two corrections to the original writeup. First, crypto.c:278 is listed in the finding's files but is not part of the defect — that static is built by hdnode_from_xpub and holds only public material. Second, CONFIDENTIAL is not inert on hardware: CMakeLists.txt:88 expands it to
__attribute__((section("confidential"))), and tools/bootloader/main.c:83 zeroes _confidential_start.._confidential_end at boot. That does NOT rescue this, though — those symbols are defined only in tools/bootloader/bootloader.ld, sized to the bootloader's own (much smaller) set of CONFIDENTIAL objects, while tools/firmware/keepkey.ld:23 declares the firmware's section with no start/end symbols and nothing zeroes it. So the firmware's node is not reliably cleared even by a warm reset into the bootloader.I rate it low rather than the recorded medium because the exploitation link is missing under the stated threat model. A malicious USB host has no memory-read primitive: KK_DEBUG_LINK defaults OFF (CMakeLists.txt:21) and there is no MemoryRead/DebugLinkMemoryRead handler in lib/firmware at all. Turning this key material into disclosure needs either a separate memory-disclosure defect or chip-level SRAM readout with physical access to a locked device — the rubric's 'low' band. It is still a genuine break of the lock guarantee (a device the user believes is locked retains a spendable account key) and deserves an issue. File it as an extension of #399's scope, naming fsm.c:193 as the highest-traffic instance and u2f.c:503 alongside it; do not hold the tag for it.
Deferred because 7.14.2 is a minimal security release; this did not clear the bar for a late change. Filed so it is not lost.