Re: [PATCH v2] iommu/vt-d: Fix copied_tables bitmap leak on error in copy_translation_tables
From: Baolu Lu
Date: Wed Jul 29 2026 - 01:39:52 EST
On 7/27/26 13:22, ZhaoJinming wrote:
The iommu->copied_tables bitmap was introduced by the IOMMU live
update series to track which context entries have been copied from
the previous kernel. The allocation via bitmap_zalloc() was added
inside copy_translation_tables(), but the error paths were not
updated to free it:
1. When old_rt_phys is 0 (invalid root table address)
2. When memremap(old_rt_phys) fails
3. When kcalloc for ctxt_tbls fails (goto out_unmap, which only
unmaps old_rt without releasing the bitmap)
The bitmap is only cleaned up by free_dmar_iommu(), which is
called from the free_iommu error label in init_dmars(). However,
when copy_translation_tables() fails, init_dmars() does not jump
to free_iommu -- it logs the error, falls through, and continues
with the next IOMMU. As a result, copied_tables is leaked.
Fix this by converting the two early returns to goto a new
err_free_bitmap label, and by making out_unmap fall through to
it so that the bitmap is always freed on any error path. The
success path performs memunmap(old_rt) inline and returns 0
directly, since copied_tables must remain allocated for
subsequent use.
---
v2:
- On the success path, call memunmap(old_rt) before returning 0
instead of returning directly, fixing a memunmap leak introduced
in v1. Suggested by Baolu Lu.
Signed-off-by: ZhaoJinming<zhaojinming@xxxxxxxxxxxxx>
Your signed-off-by should be placed above the "---" line.
---
drivers/iommu/intel/iommu.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
Queued for iommu/next with the above change applied manually.
Thanks,
baolu