What changed, and why it matters
This commit removes two lines from the bootloader update code. Previously, after a successful bootloader update, the firmware erased and overwrote a sector near the end of the application flash area, then cleared a memory buffer. Now it only clears the buffer in RAM and skips the flash erase/write. This could leave stale update data or metadata in flash, potentially allowing a previously-failed or old update marker to persist and affect future boot behavior. The change is small and its security implications depend heavily on why the erase was originally performed.
Review the bootloader and firmware update state machine to confirm whether APP_END_ADDR - SECTOR_SIZE is read elsewhere to detect pending or failed updates. If the sector is used as a status marker, ensure an alternative invalidation step exists, or restore the erase. If the erase was only for cleanup, document the rationale and add a code comment to prevent future regressions. Perform targeted testing of interrupted and repeated bootloader updates.
Security signals we found
Removal of flash erase/write after successful cryptographic verification
Persistence of update-related data in flash after update completion
Possible state-machine inconsistency if APP_END_ADDR sector is used as update flag
No compensating change visible in the diff to replace the erased sector's purpose
Evidence from the diff
In src/boot_update.c’s UpdateBootFromFlash(), on successful hash verification the code now only memsets g_fileUnit to 0xFF and returns, removing the QspiFlashEraseAndWrite() call that erased/rewrote APP_END_ADDR - SECTOR_SIZE and the subsequent zeroing of g_fileUnit. The erased sector likely served as a status flag or cleared update metadata after a successful boot update. Removing the erase means the on-flash update region is no longer invalidated after success. If the bootloader or update logic later re-reads that sector to decide whether an update is pending, it may incorrectly believe an update is still queued or may reuse stale data. Conversely, if the erase was redundant, the change is harmless. The diff alone does not show the full state machine or the reason for the original erase.
Changed components
src/boot_update.cUpdateBootFromFlash()QSPI flash update sector at APP_END_ADDR - SECTOR_SIZEInspect captured patch +0 / −2
diff --git a/src/boot_update.c b/src/boot_update.c
index 5b4bd8b..89ca8d2 100644
--- a/src/boot_update.c
+++ b/src/boot_update.c
@@ -114,8 +114,6 @@ int32_t UpdateBootFromFlash(void)
if (memcmp(hash, calHash, 32) == 0) {
printf("update success\n");
memset(g_fileUnit, 0xFF, sizeof(g_fileUnit));
- QspiFlashEraseAndWrite((uint32_t *)(APP_END_ADDR - SECTOR_SIZE), g_fileUnit, SECTOR_SIZE);
- memset(g_fileUnit, 0, sizeof(g_fileUnit));
return 0;
} else {
printf("update failed\n");
Why this scored 56/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.