Re: [RFC v2 PATCH] mm/cma: don't release CMA pages still in use

[Rik van Riel]

On Mon, 2026-08-10 at 20:53 +0200, David Hildenbrand (Arm) wrote:
> On 8/10/26 18:27, Rik van Riel wrote:
> > When a driver calls dma_free_contiguous() before quiescing DMA, the
> > page still has a reference from the device. put_page_testzero()
> > there
> > returns false, WARN fires, but the code proceeds to
> > free_contig_frozen_range() putting a live page onto buddy and
> > clearing
> > the bitmap. Later cma_alloc() hands the same PFN to a new owner
> > while
> > the original holder still references it.
> 
> Hm, it rather sounds like it's really the drivers job to quiescing
> DMA. Are you
> aware of an in-tree driver that can trigger this, and if so, how?
> 
> Freeing memory through CMA, while the memory is still in use is
> problematic for
> CMA as you discovered :)

I agree the driver should not be doing that. 

I do not know of any driver that currently does it, but
it has led to CVE-2025-37837 in the past, and there
appear to have been other cases of this issue happening.

> > +	WARN(skipped, "%lu pages are still in use!\n", skipped);
> 
> 
> We still issue a WARN, which itself is problematic. See "Do not WARN
> lightly" in
> Documentation/process/coding-style.rst.
> 
> So it's either
> 
> (a) This scenario is valid to be triggered. In that case, WARN is not
> appropriate.
> 
> (b) This scenario is not valid to be triggered. In that case, this is
> not a fix.

If a driver does it with the current code, it can 
cause free list corruption, with potential for
temporary data exposure, until the system crashes.

If we get rid of the free list corruption, it
can continue to be a WARN, since it will no longer
kill the system.

If we continue to corrupt the free list when this
happens, it should probably be a panic?

A simpler fix may be to not free any of the memory,
or the CMA address space, if there are still pages
in use at cma_release() time.

-- 
All Rights Reversed.