linux-kernel - Re: [PATCH] KVM: SVM: snp_alloc_firmware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a0d4b2ab-c20f-444a-a1ca-d0cccfe862fd@amd.com>
Date: Tue, 18 Feb 2025 12:24:58 +1100
From: Alexey Kardashevskiy <aik@....com>
To: Tom Lendacky <thomas.lendacky@....com>, linux-crypto@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Ashish Kalra <ashish.kalra@....com>
Subject: Re: [PATCH] KVM: SVM: snp_alloc_firmware_pages: memory leak



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@....com>
>> ---
>>   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