While reviewing the AVB 2.0 integration I noticed several memory leaks in the verification path that accumulate on every boot.
In the Android bootmethod, run_avb_verification() allocates an AvbOps via avb_ops_alloc() and receives an AvbSlotVerifyData from avb_slot_verify(), but frees neither on the successful return paths. Every boot therefore leaks the AvbOpsData structure, and with CONFIG_OPTEE_TA_AVB the leaked AvbOps also leaves the OP-TEE session open (it is only closed inside avb_ops_free()). The AvbSlotVerifyData - holding the kernel cmdline and loaded-partition metadata - is leaked on both the locked GREEN/OK and the unlocked ORANGE/ERROR_VERIFICATION success paths. Independently, the AvbOps I/O helpers leak a struct mmc_part on every partition access: get_partition() returns a malloc()'d descriptor that only its internal error path frees, while none of its three callers (mmc_byte_io(), get_unique_guid_for_partition(), get_size_of_partition()) release it. A single "avb verify" performs many such accesses (footer, vbmeta and the hashed image chunks), so this leak grows quickly. No functional change intended: the GREEN/ORANGE boot-state handling and the locked/unlocked acceptance logic are preserved. Signed-off-by: Igor Opaniuk <[email protected]> --- Igor Opaniuk (2): boot: android: fix AvbOps and verify-data leaks in AVB path avb: free mmc_part allocated by get_partition() boot/bootmeth_android.c | 37 +++++++++++++++++++++---------------- common/avb_verify.c | 29 +++++++++++++++++++++-------- 2 files changed, 42 insertions(+), 24 deletions(-) --- base-commit: 6741b0dfb41dc82a284ab1cff4c58af6ef2f3f9c change-id: 20260712-avb-fix-memory-leaks-831cfd7e2115 Best regards, -- Igor Opaniuk <[email protected]>
