[v1] aspeed/hace: Fix mapped address may not be unmapped issue

[PATCH v1 0/1] aspeed/hace: Fix mapped address may not be unmapped issue

Posted by Kane Chen 2 weeks, 3 days ago

Dear reviewer,

The Aspeed HACE hash flow may leave DMA mappings active when an error
occurs after guest buffers have already been mapped.

Several failure paths return early without unmapping previously mapped
iov entries. This can lead to stale mappings and resource leaks.

Fix this by introducing a common cleanup helper that unmaps all
previously mapped iov entries before returning from error paths.

Additionally, track the actual mapped length of each iov entry
explicitly. This is necessary because some hashing flows may apply
padding during processing, and the resulting buffer length used later
in the flow can differ from the original DMA mapped length. Using the
modified length during dma_memory_unmap() may result in an incorrect
unmap size.

Note: this patch series is based on 
https://patchew.org/QEMU/20260504213421.710035-1-clg@redhat.com/.

Best Regards,
Kane

Kane-Chen-AS (1):
  aspeed/hace: Fix mapped address may not be unmapped issue

 hw/misc/aspeed_hace.c | 63 ++++++++++++++++++++++++++++++-------------
 1 file changed, 45 insertions(+), 18 deletions(-)

-- 
2.43.0

Re: [PATCH v1 0/1] aspeed/hace: Fix mapped address may not be unmapped issue

Posted by Cédric Le Goater 2 weeks, 2 days ago

On 5/8/26 07:16, Kane Chen wrote:
> Dear reviewer,
> 
> The Aspeed HACE hash flow may leave DMA mappings active when an error
> occurs after guest buffers have already been mapped.
> 
> Several failure paths return early without unmapping previously mapped
> iov entries. This can lead to stale mappings and resource leaks.
> 
> Fix this by introducing a common cleanup helper that unmaps all
> previously mapped iov entries before returning from error paths.
> 
> Additionally, track the actual mapped length of each iov entry
> explicitly. This is necessary because some hashing flows may apply
> padding during processing, and the resulting buffer length used later
> in the flow can differ from the original DMA mapped length. Using the
> modified length during dma_memory_unmap() may result in an incorrect
> unmap size.
> 
> Note: this patch series is based on
> https://patchew.org/QEMU/20260504213421.710035-1-clg@redhat.com/.
> 
> Best Regards,
> Kane
Jamin, I need your help here too.

Thanks,

C.

RE: [PATCH v1 0/1] aspeed/hace: Fix mapped address may not be unmapped issue

Posted by Jamin Lin 1 week, 6 days ago

Hi Cédric,

> Subject: Re: [PATCH v1 0/1] aspeed/hace: Fix mapped address may not be
> unmapped issue
> 
> On 5/8/26 07:16, Kane Chen wrote:
> > Dear reviewer,
> >
> > The Aspeed HACE hash flow may leave DMA mappings active when an error
> > occurs after guest buffers have already been mapped.
> >
> > Several failure paths return early without unmapping previously mapped
> > iov entries. This can lead to stale mappings and resource leaks.
> >
> > Fix this by introducing a common cleanup helper that unmaps all
> > previously mapped iov entries before returning from error paths.
> >
> > Additionally, track the actual mapped length of each iov entry
> > explicitly. This is necessary because some hashing flows may apply
> > padding during processing, and the resulting buffer length used later
> > in the flow can differ from the original DMA mapped length. Using the
> > modified length during dma_memory_unmap() may result in an incorrect
> > unmap size.
> >
> > Note: this patch series is based on
> > https://patchew.org/QEMU/20260504213421.710035-1-clg@redhat.com/.
> >
> > Best Regards,
> > Kane
> Jamin, I need your help here too.
> 
Looks good to me.
Added review-tag.

Thanks,
Jamin

> Thanks,
> 
> C.
>