feat(core): disable stack protector in syscall stubs
What the developer wrote
Authored by cepetr
feat(core): disable stack protector in syscall stubs
[no changelog]
What changed, and why it matters
This commit changes a low-level firmware file that handles system calls on Trezor hardware wallets. It disables the compiler's stack protector (a safety feature that helps detect certain memory corruption bugs) specifically in the 'syscall stubs' code. The commit message frames this as a feature and does not explain why the protector is being disabled or claim any security benefit. On its own, disabling a security mitigation is a security signal, but the diff is too small to determine whether this introduces a real vulnerability or is a necessary workaround for a technical constraint.
Treat as a low-signal defensive finding. Review the syscall stubs for stack-buffer-overflow exposure now that stack canaries are absent, confirm the pragma is required (e.g., due to canary initialization ordering or fixed stack layout), and request the vendor to document the rationale in a code comment or changelog. No immediate exploit is evident from the diff alone.
Security signals we found
Disables stack protector (stack canary) mitigation in syscall stubs
Affects code that transitions between unprivileged and kernel mode
No changelog entry or documented rationale for removing the mitigation
Small, single-file change with no accompanying test or advisory
Evidence from the diff
The patch adds #pragma GCC optimize("no-stack-protector") at the top of core/embed/sys/syscall/stm32/syscall_stubs.c and moves the #include <trezor_types.h> below it. The pragma disables GCC’s stack canary generation for functions in this translation unit. Syscall stubs are small trampoline functions that transition from unprivileged/user mode into kernel mode on the STM32; they may have strict stack-layout requirements or run before the stack canary value is initialized. The commit provides no rationale, changelog entry, or references. There is no direct evidence of an exploitable bug, but removing a stack-based exploit mitigation in privileged-transition code is a defensive concern.
Changed components
core/embed/sys/syscall/stm32/syscall_stubs.cTrezor Core firmware STM32 syscall layerUnprivileged-to-kernel mode transition codeInspect captured patch +4 / −2
diff --git a/core/embed/sys/syscall/stm32/syscall_stubs.c b/core/embed/sys/syscall/stm32/syscall_stubs.c
index c19c51c5e..ae794e8c3 100644
--- a/core/embed/sys/syscall/stm32/syscall_stubs.c
+++ b/core/embed/sys/syscall/stm32/syscall_stubs.c
@@ -17,10 +17,12 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
-#include <trezor_types.h>
-
#ifndef KERNEL_MODE
+#pragma GCC optimize("no-stack-protector")
+
+#include <trezor_types.h>
+
#include "syscall_internal.h"
// =============================================================================
Why this scored 26/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.