On Mon, Oct 5, 2026 at 11:34 PM Ahmad Fatoum <[email protected]> wrote: > > Hi. > > I am quite ignorant about how Android Verified Boot works, but looking > through the code in both cmd/avb.c and bootmeth_android.c, I wonder how > this could not be susceptible to a TOCTOU attack: > > - do_avb_verify_part() does avb_slot_verify() and then discards what it > verified with avb_slot_verify_data_free() > > - run_avb_verification() leaks AvbSlotVerifyData *out_data and doesn't > seem to use it anywhere > > So it looks like an attacker able to interpose the storage device should > be trivially able to circumvent both of these? Am I missing something? > > Cheers, > Ahmad > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > Hi Ahmad,
You're right, and this is a known limitation rather than a new finding. Initially, the verification and loading steps were never designed to share bytes (and it was a deliberate trade-off). The gap comes from how the feature grew in two steps. 2018: avb verify was added as a shell command. It landed in the boot-script era, where the only way to pass data between commands is the environment. So the command exported what fits in a string, the cmdline, returned pass or fail, and freed libavb's buffers. Boards already had mmc read plus bootm sequences, and the command was dropped in as a gate in front of them. The threat model was offline flash tampering, where verify-then-reread is sound. libavb's get_preloaded_partition op was in the tree but never implemented, since the shell contract had no way to pass load addresses. 2024: the bootmeth basically reimplemented the same steps as was done in the script. The commit message describes it as a rewrite of the meson64_android.h script and lists "run AVB" and "load boot partitions" as separate steps. The C code mirrors that, using the sizes recorded at bootflow scan and a fresh read into loadaddr. Copying tens of megabytes out of libavb's heap buffers looked wasteful, and the preloaded path would have meant restructuring to load first and verify in place. I was planning to address that, it's on my todo list, but I haven't found the time yet to play with this. -- Best regards - Atentamente - Meilleures salutations Igor Opaniuk mailto: [email protected] skype: igor.opanyuk https://www.linkedin.com/in/iopaniuk
