What the developer wrote
Authored by Marko Bencun
Limit SD erase file size
Reject files larger than SD_MAX_FILE_SIZE before the erase path overwrites them.
The read path already enforced this limit; applying it to erase prevents a
malformed FAT directory entry from causing an excessive overwrite loop.
This mitigates the BitBox impact of CVE-2026-6682 in the stale-backup cleanup
path without changing vendored FatFs code.
What changed, and why it matters
This commit fixes a bug in how the BitBox02 hardware wallet wipes files from its SD card. Before erasing a file, the device now checks the file's reported size against a safe maximum. Without this check, a tampered SD card could claim a file is gigantic, causing the device to get stuck in a long overwrite loop. The fix prevents a denial-of-service style attack where a malicious or corrupted SD card could make the device hang or behave unexpectedly during cleanup of old backups. The commit says it mitigates the impact of CVE-2026-6682 without changing the third-party FAT filesystem code.
Apply this patch. Additionally, review whether other SD card operations (delete, rename, stat, iteration) trust FAT directory entry sizes without validation, and consider centralizing size validation at the FatFs wrapper layer. Evaluate whether a watchdog or timeout is needed for long-running SD operations on a security device.
Security signals we found
CVE-2026-6682 referenced in commit message
Malformed FAT directory entry could cause excessive overwrite loop
Denial-of-service via SD card tampering
Size limit bypass between read and erase paths
Mitigation applied without modifying vendored FatFs code
Evidence from the diff
In src/sd.c, the _delete_file() function opens a file, then overwrites it byte-by-byte with 0xAC before deleting it. Previously, the loop used file_object.obj.objsize directly without validating it. A malformed FAT directory entry could set objsize to a very large value, causing an excessive overwrite loop. The patch adds a size check against SD_MAX_FILE_SIZE (the same limit already enforced on the read path) immediately after f_open and before the overwrite loop. If the file is too large, it is closed and the function returns false. This is a mitigation for CVE-2026-6682 in the stale-backup cleanup path, applied outside the vendored FatFs library.
Changed components
src/sd.c_delete_file()SD card file erase pathstale backup cleanup pathInspect captured patch +4 / −0
diff --git a/src/sd.c b/src/sd.c
index a31c6e5..8316d17 100644
--- a/src/sd.c
+++ b/src/sd.c
@@ -370,6 +370,10 @@ static bool _delete_file(const char* fn, const char* subdir)
if (result != FR_OK) {
return false;
}
+ if (f_size(&file_object) > SD_MAX_FILE_SIZE) {
+ f_close(&file_object);
+ return false;
+ }
for (DWORD f_ps = 0; f_ps < file_object.obj.objsize; f_ps++) {
f_putc('\xAC', &file_object); // overwrite data
}
Why this scored 59/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.