Hi Ahmad, On Wed, Oct 07, 2026 at 08:03, Igor Opaniuk <[email protected]> wrote:
> Hi Ahmad, > > 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 I believe the leak you mentions has been reported and fixed by Igor here: https://lore.kernel.org/all/[email protected]/ >> >> 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 | >> > > 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). For the TOCTOU part, I agree with Igor, you are totally right. Thank you for reporting this. It looks like Igor submitted a series that is fixing this here: https://lore.kernel.org/all/20261012-upstream-avb_lock_unlock_b4-v2-3-87460a24e...@oss.qualcomm.com/ Regards, Mattijs > > 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
