AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 25 Bitcoin

fix(core/xtask): pad a combined image's erased regions as erased

Public commit record

What the developer wrote

Authored by tychovrahe

95/100 · Strong
fix(core/xtask): pad a combined image's erased regions as erased

A combined image pads the gaps between its sections with 0x00. That is
wrong for any region the boot chain ERASES on first boot: the bootloader
erases the UCB (`boot_ucb_erase`), so the device stops matching the
image it was flashed from the moment it boots, and a factory line that
verifies by reading flash back would fail.

Pad that region with 0xFF, the erased state, and the erase becomes a
no-op -- it checks `flash_area_is_erased` and skips -- leaving the image
byte-identical to what is on the device. The rule generalises: a region
the boot chain erases has to be combined in its erased state.

The region is located from the model's memory.ld, so a model without one
is untouched; both cases are covered by tests.

[no changelog]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a build-time tooling bug in Trezor's firmware build helper. When creating a combined firmware image, the tool was filling unused gaps between sections with 0x00 bytes. One specific gap (the UCB region) is erased by the bootloader on first boot. Because erased flash reads as 0xFF, the device would no longer match the original image after its first boot, causing factory verification to fail. The fix makes the tool fill that gap with 0xFF instead, so the image stays identical after the device boots. This is a manufacturing/verification bug, not a security vulnerability that can be exploited by an attacker.

Recommended action

No urgent security action required. Ensure build pipelines pick up the fixed `xtask` binary so factory-flashed combined images are byte-identical after first boot. Treat as a build-quality/manufacturing reliability fix rather than a vulnerability patch.

Security signals we found

01

Boot chain behavior mismatch between host-generated image and device-erased flash

02

Factory verification failure due to byte-level image divergence after first boot

03

Host-side build tooling correction with no firmware/bootloader runtime change

04

Region identified from linker script symbols (BOOTUCB_START / BOOTUCB_MAXSIZE)

Risk score

Why this scored 25/100

Our methodology →
Potential impact 8/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.