Re: [PATCH] dma-buf: move system_cc_shared heap under separate Kconfig

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unconditional page re-encryption in error path causes potential memory leak and invalid hypercalls
--

commit 611c6660a2bb2f9f324ce349cfce6b2530846d28
Author: Arnd Bergmann <arnd@arndb.de>

dma-buf: move system_cc_shared heap under separate Kconfig

This commit moves the system_cc_shared heap into its own Kconfig symbol,
DMABUF_HEAPS_CC_SYSTEM. This resolves a build failure on architectures like
powerpc and s390 when the system heap is built as a loadable module, since
the set_memory_encrypted and set_memory_decrypted functions are not
exported to modules.

> diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c
> index c92bdec356fcc..71d9028cc3dfc 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
[ ... ]
> @@ -485,7 +488,7 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
>  		 * Intentionally leak pages that cannot be re-encrypted
>  		 * to prevent shared memory from being reused.
>  		 */
> -		if (buffer->cc_shared &&
> +		if (cc_shared_buffer(buffer) &&
>  		    system_heap_set_page_encrypted(p))
>  			continue;
>  		__free_pages(p, compound_order(p));

[Severity: High]
This isn't a bug introduced by this patch, but does this error path
unintentionally re-encrypt pages that were never decrypted?

If system_heap_set_page_decrypted() fails during the earlier loop in
system_heap_allocate(), it jumps to the free_pages label. However, the
cleanup loop here uses for_each_sgtable_sg(table, sg, i), which iterates
over the entire scatterlist starting from index 0.

This means pages after the failure point, which were never decrypted, will
still be passed to system_heap_set_page_encrypted(). If the underlying
set_memory_encrypted() call fails on already-encrypted pages (e.g., due to
hypervisor state enforcement), the code skips __free_pages() and leaks the
memory.

Could this loop be modified to only re-encrypt the pages that were
successfully decrypted before the failure?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610142329.3836808-1-sumit.semwal@linaro.org?part=1