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

[David Hildenbrand (Arm)]

On 8/11/26 05:49, Rik van Riel wrote:
> 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.

Yes, keep it as simple as possible and complain.

This is really something that must not happen, and the CVE in that above case is
not this code's fault but the driver's fault.

-- 
Cheers,

David