fix(core): use verifiers for translations syscalls
What the developer wrote
Authored by tychovrahe
fix(core): use verifiers for translations syscalls
[no changelog]
What changed, and why it matters
This commit changes two system call handlers in Trezor's firmware so that translation-related read/write operations go through 'verified' versions of functions. The change suggests the previous unverified versions may have allowed untrusted code (apps running on the device) to access or modify translation data in unsafe ways, such as passing bad memory pointers or lengths. Without the verified wrapper, a malicious or buggy app could potentially corrupt memory or read/write data it should not. The patch is very small and does not show the verifier code itself, so we cannot confirm the exact bug or exploit path.
Review the implementations of translations_write__verified and translations_read__verified to confirm they validate data, offset, len, and the len output pointer against caller-accessible memory. Audit other syscalls in the same dispatch table for similar missing verification wrappers. Consider whether this change warrants a security advisory or CVE if unprivileged code could exploit the prior unverified path.
Security signals we found
Syscall dispatch now routes through __verified variants
Change limited to translation read/write syscalls; erase syscall already used verified form or was not changed
Implies missing input validation on pointer and length arguments
Potential memory safety / privilege boundary issue between kernel and app/runtime
No changelog entry and no explicit security disclosure in commit metadata
Evidence from the diff
In core/embed/sys/syscall/stm32/syscall_dispatch.c, the SYSCALL_TRANSLATIONS_WRITE and SYSCALL_TRANSLATIONS_READ dispatch cases now call translations_write__verified() and translations_read__verified() instead of translations_write() and translations_read(). The __verified suffix implies input validation wrappers that likely check pointer/length arguments against allowed application memory regions before performing the operation. The unverified variants were presumably reachable from unprivileged firmware contexts via the syscall table. The patch is partial: it shows the dispatch change but not the verifier implementations or the original vulnerable behavior, so the precise flaw remains inferred.
Changed components
core/embed/sys/syscall/stm32/syscall_dispatch.cSYSCALL_TRANSLATIONS_WRITE handlerSYSCALL_TRANSLATIONS_READ handlertranslations_write / translations_read kernel functionsTrezor Core firmware syscall layerInspect captured patch +2 / −2
diff --git a/core/embed/sys/syscall/stm32/syscall_dispatch.c b/core/embed/sys/syscall/stm32/syscall_dispatch.c
index 9f2ed3ec..9b6d6d40 100644
--- a/core/embed/sys/syscall/stm32/syscall_dispatch.c
+++ b/core/embed/sys/syscall/stm32/syscall_dispatch.c
@@ -618,13 +618,13 @@ __attribute((no_stack_protector)) void syscall_handler(uint32_t *args,
const uint8_t *data = (const uint8_t *)args[0];
uint32_t offset = args[1];
uint32_t len = args[2];
- args[0] = translations_write(data, offset, len);
+ args[0] = translations_write__verified(data, offset, len);
} break;
case SYSCALL_TRANSLATIONS_READ: {
uint32_t *len = (uint32_t *)args[0];
uint32_t offset = args[1];
- args[0] = (uint32_t)translations_read(len, offset);
+ args[0] = (uint32_t)translations_read__verified(len, offset);
} break;
case SYSCALL_TRANSLATIONS_ERASE: {
Why this scored 63/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.