display: add check for screen power on status
What changed, and why it matters
This tiny change makes the device firmly check that the screen successfully powers on during startup, rather than silently continuing if something goes wrong. It is a defensive hardening fix, not a clear-cut vulnerability patch. The commit message and diff do not describe any attack or security incident.
Treat as low-priority hardening. Review whether other initialization functions in display_init() and related startup paths similarly ignore error codes, and consider consistent error handling rather than assertions where recovery is possible.
Security signals we found
Unchecked return value now checked with JADE_ASSERT
Defensive hardening in display initialization path
No mention of vulnerability, exploit, or security issue in commit message
Evidence from the diff
In main/display.c, display_init() now asserts that power_screen_on() returns ESP_OK. Previously the return value was discarded. This converts a silent failure during display initialization into a startup assertion failure. It is a hardening measure; the commit provides no evidence that an attacker could exploit the previous unchecked return value, nor does it describe a specific security bug.
Changed components
main/display.cdisplay_init()power_screen_on()Inspect captured patch +1 / −1
diff --git a/main/display.c b/main/display.c
index c5f6ff2..bb0d10c 100644
--- a/main/display.c
+++ b/main/display.c
@@ -243,7 +243,7 @@ void display_init(TaskHandle_t* gui_h)
#endif
JADE_ASSERT(!*gui_h);
- power_screen_on();
+ JADE_ASSERT(power_screen_on() == ESP_OK);
vTaskDelay(100 / portTICK_PERIOD_MS);
#if defined(CONFIG_ETH_USE_OPENETH)
Why this scored 18/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.