Re: [PATCH] KVM: SVM: snp_alloc_firmware_pages: memory leak

[Alexey Kardashevskiy]

On 15/2/25 01:53, Tom Lendacky wrote:
> On 2/13/25 21:59, Alexey Kardashevskiy wrote:
> > Failure to rmpupdate leads to page(s) leak, fix that.
> >
> > Signed-off-by: Alexey Kardashevskiy <aik@xxxxxxx>
> > ---
> >   drivers/crypto/ccp/sev-dev.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> > index 2e87ca0e292a..0b5f8ab657c5 100644
> > --- a/drivers/crypto/ccp/sev-dev.c
> > +++ b/drivers/crypto/ccp/sev-dev.c
> > @@ -443,8 +443,10 @@ static struct page *__snp_alloc_firmware_pages(gfp_t gfp_mask, int order)
> >   		return page;
> >   
> >   	paddr = __pa((unsigned long)page_address(page));
> > -	if (rmp_mark_pages_firmware(paddr, npages, false))
> > +	if (rmp_mark_pages_firmware(paddr, npages, false)) {
> > +		__free_pages(page, order);
>
> I'm not sure we can do this. On error, rmp_mark_pages_firmware() attempts
> to cleanup and restore any pages that were marked firmware. But
> snp_reclaim_pages() will leak pages that it can't restore and we don't
> pass back any info to the caller of rmp_mark_pages_firmware() to let it
> know what pages are truly available to free.

oh right. But there is snp_leaked_pages_list which 
__snp_alloc_firmware_pages() could look at.

Or just replace __free_pages() above with:

snp_leak_pages(__page_to_pfn(page), 1 << order)

so memory leak leaves traces in dmesg, at least?


> Thanks,
> Tom
>
> >   		return NULL;
> > +	}
> >   
> >   	return page;
> >   }

--
Alexey