AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 32 Bitcoin

feat(core): implement applet unload

Public commit record

What the developer wrote

Authored by cepetr

57/100 · Thin
feat(core): implement applet unload

[no changelog]
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The short version

What changed, and why it matters

This commit rewrites how the Trezor firmware's kernel cleans up after the main user-interface app (the 'coreapp') finishes or crashes. It replaces a simple 'stop' function with a new 'unload' path that always clears the app's memory and, on real hardware, disables the special memory/peripheral access rights that were granted while the app ran. The change also adds a check so the kernel only tries to clean up tasks that were actually initialized. Overall it looks like a hardening/cleanup improvement rather than a new vulnerability, though the commit is a refactor and the diff alone cannot prove no bugs were introduced.

Recommended action

Treat as a normal code-quality/security-hardening change. Reviewers should verify that coreapp_unload_cb() is always invoked before the next coreapp is loaded, that mpu_set_active_applet(NULL) cannot leave the MPU in an unexpectedly permissive state, and that the new 'initialized' flag is set atomically enough relative to systask_is_alive() checks. No immediate security response is indicated by the diff alone.

Security signals we found

01

Memory-clearing and privilege-revocation logic moved into a single unload callback, reducing the chance that a code path forgets to reset TrustZone/MPU permissions

02

New systask_t.initialized guard prevents operations on partially-initialized task structures

03

applet_unload() now terminates the task if it is still alive before releasing resources, which may reduce windows where a live task retains access after cleanup begins

04

Refactor removes duplicated stm32/unix applet.c logic, lowering maintenance risk but also changing execution order of security-relevant teardown

Risk score

Why this scored 32/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.