[PATCH 0/2] avb: fix memory leaks in AVB 2.0 verification path

[PATCH 0/2] avb: fix memory leaks in AVB 2.0 verification path

[Igor Opaniuk]

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 <igor.opaniuk@gmail.com>
---
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 <igor.opaniuk@gmail.com>

[PATCH 1/2] boot: android: fix AvbOps and verify-data leaks in AVB path

[Igor Opaniuk]

run_avb_verification() allocates an AvbOps via avb_ops_alloc() but never
frees it on any return path. Every Android boot attempt therefore leaks
the AvbOpsData structure and, when CONFIG_OPTEE_TA_AVB is enabled, leaves
the OP-TEE session open (it is only closed inside avb_ops_free()).

In addition, the AvbSlotVerifyData returned by avb_slot_verify() is only
released on the failure branches. The successful "return 0" paths (both
the locked GREEN/OK case and the unlocked ORANGE/ERROR_VERIFICATION case)
return without freeing it, leaking the whole out_data (cmdline and loaded
partition metadata) on every good boot.

Route all exit paths through a single cleanup label that frees both
out_data and avb_ops.

Fixes: 125d9f3306ea ("bootstd: Add a bootmeth for Android")
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
---
 boot/bootmeth_android.c | 37 +++++++++++++++++++++----------------
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/boot/bootmeth_android.c b/boot/bootmeth_android.c
index 1d70e8d5c05..ec255b072af 100644
--- a/boot/bootmeth_android.c
+++ b/boot/bootmeth_android.c
@@ -428,7 +428,7 @@ static int run_avb_verification(struct bootflow *bflow)
 	const char * const requested_partitions[] = {"boot", "vendor_boot", NULL};
 	struct AvbOps *avb_ops;
 	AvbSlotVerifyResult result;
-	AvbSlotVerifyData *out_data;
+	AvbSlotVerifyData *out_data = NULL;
 	enum avb_boot_state boot_state;
 	char *extra_args;
 	char slot_suffix[3] = "";
@@ -443,8 +443,10 @@ static int run_avb_verification(struct bootflow *bflow)
 		sprintf(slot_suffix, "_%s", priv->slot);
 
 	ret = avb_ops->read_is_device_unlocked(avb_ops, &unlocked);
-	if (ret != AVB_IO_RESULT_OK)
-		return log_msg_ret("avb lock", -EIO);
+	if (ret != AVB_IO_RESULT_OK) {
+		ret = log_msg_ret("avb lock", -EIO);
+		goto out;
+	}
 
 	result = avb_slot_verify(avb_ops,
 				 requested_partitions,
@@ -458,9 +460,8 @@ static int run_avb_verification(struct bootflow *bflow)
 		if (result != AVB_SLOT_VERIFY_RESULT_OK) {
 			printf("Verification failed, reason: %s\n",
 			       str_avb_slot_error(result));
-			if (out_data)
-				avb_slot_verify_data_free(out_data);
-			return log_msg_ret("avb verify", -EIO);
+			ret = log_msg_ret("avb verify", -EIO);
+			goto out;
 		}
 		boot_state = AVB_GREEN;
 	} else {
@@ -469,9 +470,8 @@ static int run_avb_verification(struct bootflow *bflow)
 		    result != AVB_SLOT_VERIFY_RESULT_ERROR_VERIFICATION) {
 			printf("Unlocked verification failed, reason: %s\n",
 			       str_avb_slot_error(result));
-			if (out_data)
-				avb_slot_verify_data_free(out_data);
-			return log_msg_ret("avb verify unlocked", -EIO);
+			ret = log_msg_ret("avb verify unlocked", -EIO);
+			goto out;
 		}
 		boot_state = AVB_ORANGE;
 	}
@@ -480,23 +480,28 @@ static int run_avb_verification(struct bootflow *bflow)
 	if (extra_args) {
 		/* extra_args will be modified after this. This is fine */
 		ret = avb_append_commandline_arg(bflow, extra_args);
-		if (ret < 0)
-			goto free_out_data;
+		if (ret < 0) {
+			ret = log_msg_ret("avb cmdline", ret);
+			goto out;
+		}
 	}
 
 	if (result == AVB_SLOT_VERIFY_RESULT_OK) {
 		ret = avb_append_commandline(bflow, out_data->cmdline);
-		if (ret < 0)
-			goto free_out_data;
+		if (ret < 0) {
+			ret = log_msg_ret("avb cmdline", ret);
+			goto out;
+		}
 	}
 
-	return 0;
+	ret = 0;
 
- free_out_data:
+ out:
 	if (out_data)
 		avb_slot_verify_data_free(out_data);
+	avb_ops_free(avb_ops);
 
-	return log_msg_ret("avb cmdline", ret);
+	return ret;
 }
 #else
 static int run_avb_verification(struct bootflow *bflow)

-- 
2.53.0

Re: [PATCH 1/2] boot: android: fix AvbOps and verify-data leaks in AVB path

[Mattijs Korpershoek]

Hi Igor,

Thank you for the patch.

On Sun, Jul 12, 2026 at 10:50, Igor Opaniuk <igor.opaniuk@gmail.com> wrote:

> run_avb_verification() allocates an AvbOps via avb_ops_alloc() but never
> frees it on any return path. Every Android boot attempt therefore leaks
> the AvbOpsData structure and, when CONFIG_OPTEE_TA_AVB is enabled, leaves
> the OP-TEE session open (it is only closed inside avb_ops_free()).
>
> In addition, the AvbSlotVerifyData returned by avb_slot_verify() is only
> released on the failure branches. The successful "return 0" paths (both
> the locked GREEN/OK case and the unlocked ORANGE/ERROR_VERIFICATION case)
> return without freeing it, leaking the whole out_data (cmdline and loaded
> partition metadata) on every good boot.
>
> Route all exit paths through a single cleanup label that frees both
> out_data and avb_ops.
>
> Fixes: 125d9f3306ea ("bootstd: Add a bootmeth for Android")
> Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>

Good catch. Thank you for this!

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

[PATCH 2/2] avb: free mmc_part allocated by get_partition()

[Igor Opaniuk]

get_partition() returns a malloc()'d struct mmc_part and only frees it on
its own internal error path. None of its callers - mmc_byte_io(),
get_unique_guid_for_partition() and get_size_of_partition() - free the
returned pointer, so every partition access leaks one struct mmc_part.
A single "avb verify" issues many such accesses (footer, vbmeta and the
hashed image chunks), so the leak accumulates quickly.

Free the descriptor in all three callers. mmc_byte_io() is reworked to
use a single exit path so the partition is released on every return.

Fixes: 3af30e4443aa ("avb2.0: implement AVB ops")
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
---
 common/avb_verify.c | 29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/common/avb_verify.c b/common/avb_verify.c
index 29a3272579c..76c523fd0ba 100644
--- a/common/avb_verify.c
+++ b/common/avb_verify.c
@@ -452,6 +452,7 @@ static AvbIOResult mmc_byte_io(AvbOps *ops,
 	u64 start_offset, start_sector, sectors, residue;
 	u8 *tmp_buf;
 	size_t io_cnt = 0;
+	AvbIOResult io_ret = AVB_IO_RESULT_OK;
 
 	if (!partition || !buffer || io_type > IO_WRITE)
 		return AVB_IO_RESULT_ERROR_IO;
@@ -460,8 +461,10 @@ static AvbIOResult mmc_byte_io(AvbOps *ops,
 	if (!part)
 		return AVB_IO_RESULT_ERROR_NO_SUCH_PARTITION;
 
-	if (!part->info.blksz)
-		return AVB_IO_RESULT_ERROR_IO;
+	if (!part->info.blksz) {
+		io_ret = AVB_IO_RESULT_ERROR_IO;
+		goto out;
+	}
 
 	start_offset = calc_offset(part, offset);
 	while (num_bytes) {
@@ -489,7 +492,8 @@ static AvbIOResult mmc_byte_io(AvbOps *ops,
 				if (ret != 1) {
 					printf("%s: read error (%ld, %lld)\n",
 					       __func__, ret, start_sector);
-					return AVB_IO_RESULT_ERROR_IO;
+					io_ret = AVB_IO_RESULT_ERROR_IO;
+					goto out;
 				}
 				/*
 				 * if this is not aligned at sector start,
@@ -506,7 +510,8 @@ static AvbIOResult mmc_byte_io(AvbOps *ops,
 				if (ret != 1) {
 					printf("%s: read error (%ld, %lld)\n",
 					       __func__, ret, start_sector);
-					return AVB_IO_RESULT_ERROR_IO;
+					io_ret = AVB_IO_RESULT_ERROR_IO;
+					goto out;
 				}
 				memcpy((void *)tmp_buf +
 					start_offset % part->info.blksz,
@@ -517,7 +522,8 @@ static AvbIOResult mmc_byte_io(AvbOps *ops,
 				if (ret != 1) {
 					printf("%s: write error (%ld, %lld)\n",
 					       __func__, ret, start_sector);
-					return AVB_IO_RESULT_ERROR_IO;
+					io_ret = AVB_IO_RESULT_ERROR_IO;
+					goto out;
 				}
 			}
 
@@ -543,7 +549,8 @@ static AvbIOResult mmc_byte_io(AvbOps *ops,
 
 			if (!ret) {
 				printf("%s: sector read error\n", __func__);
-				return AVB_IO_RESULT_ERROR_IO;
+				io_ret = AVB_IO_RESULT_ERROR_IO;
+				goto out;
 			}
 
 			io_cnt += ret * part->info.blksz;
@@ -557,7 +564,9 @@ static AvbIOResult mmc_byte_io(AvbOps *ops,
 	if (io_type == IO_READ && out_num_read)
 		*out_num_read = io_cnt;
 
-	return AVB_IO_RESULT_OK;
+out:
+	free(part);
+	return io_ret;
 }
 
 /**
@@ -867,12 +876,15 @@ static AvbIOResult get_unique_guid_for_partition(AvbOps *ops,
 		return AVB_IO_RESULT_ERROR_NO_SUCH_PARTITION;
 
 	uuid_size = sizeof(part->info.uuid);
-	if (uuid_size > guid_buf_size)
+	if (uuid_size > guid_buf_size) {
+		free(part);
 		return AVB_IO_RESULT_ERROR_IO;
+	}
 
 	memcpy(guid_buf, part->info.uuid, uuid_size);
 	guid_buf[uuid_size - 1] = 0;
 
+	free(part);
 	return AVB_IO_RESULT_OK;
 }
 
@@ -903,6 +915,7 @@ static AvbIOResult get_size_of_partition(AvbOps *ops,
 		return AVB_IO_RESULT_ERROR_NO_SUCH_PARTITION;
 
 	*out_size_num_bytes = part->info.blksz * part->info.size;
+	free(part);
 
 	return AVB_IO_RESULT_OK;
 }

-- 
2.53.0

Re: [PATCH 2/2] avb: free mmc_part allocated by get_partition()

[Mattijs Korpershoek]

Hi Igor,

Thank you for the patch.

On Sun, Jul 12, 2026 at 10:50, Igor Opaniuk <igor.opaniuk@gmail.com> wrote:

> get_partition() returns a malloc()'d struct mmc_part and only frees it on
> its own internal error path. None of its callers - mmc_byte_io(),
> get_unique_guid_for_partition() and get_size_of_partition() - free the
> returned pointer, so every partition access leaks one struct mmc_part.
> A single "avb verify" issues many such accesses (footer, vbmeta and the
> hashed image chunks), so the leak accumulates quickly.
>
> Free the descriptor in all three callers. mmc_byte_io() is reworked to
> use a single exit path so the partition is released on every return.
>
> Fixes: 3af30e4443aa ("avb2.0: implement AVB ops")
> Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

Re: [PATCH 0/2] avb: fix memory leaks in AVB 2.0 verification path

[Igor Opaniuk]

On Sun, Jul 12, 2026 at 10:50 AM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:
>
> 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 <igor.opaniuk@gmail.com>
> ---
> 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 <igor.opaniuk@gmail.com>
>

Just a gentle ping on this patch series

-- 
Best regards - Atentamente - Meilleures salutations

Igor Opaniuk

mailto: igor.opaniuk@gmail.com
https://www.linkedin.com/in/iopaniuk

Re: [PATCH 0/2] avb: fix memory leaks in AVB 2.0 verification path

[Mattijs Korpershoek via U-Boot]

Hi Igor,

On Wed, Jul 15, 2026 at 18:29, Igor Opaniuk <igor.opaniuk@gmail.com> wrote:

> On Sun, Jul 12, 2026 at 10:50 AM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:
>>
>> 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 <igor.opaniuk@gmail.com>
>> ---
>> 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 <igor.opaniuk@gmail.com>
>>
>
> Just a gentle ping on this patch series

Sorry, I was on vacation and away from my computer. I will review this
week.

Thanks for your patience!
Mattijs

>
> -- 
> Best regards - Atentamente - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opaniuk@gmail.com
> https://www.linkedin.com/in/iopaniuk

Re: [PATCH 0/2] avb: fix memory leaks in AVB 2.0 verification path

[Mattijs Korpershoek]

Hi,

On Sun, 12 Jul 2026 10:50:19 +0200, Igor Opaniuk wrote:
> 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.
> 
> [...]

Thanks, Applied to https://git.u-boot-project.org/u-boot/custodians/u-boot-dfu (u-boot-dfu)

[1/2] boot: android: fix AvbOps and verify-data leaks in AVB path
      https://git.u-boot-project.org/u-boot/custodians/u-boot-dfu/-/commit/a7f65a6b6abc7119394e1ae7f16e3c60d39166c8
[2/2] avb: free mmc_part allocated by get_partition()
      https://git.u-boot-project.org/u-boot/custodians/u-boot-dfu/-/commit/f9c750ea306877432a525de1ebd9740ec815e5da

--
Mattijs