[PATCH] x86/sev: Fix kmemleak false positive for the RMP segment descriptors

[PATCH] x86/sev: Fix kmemleak false positive for the RMP segment descriptors

[Breno Leitao]

kmemleak reports the RMP segment descriptor as leaked on SEV-SNP hosts:

  unreferenced object 0xff11000140e23b40 (size 32):
    comm "swapper/0", pid 1, jiffies 4294680964
    hex dump (first 32 bytes):
      00 00 00 40 00 00 a0 ff 00 fc 05 04 00 00 00 00  ...@............
      00 c0 5f 40 00 00 00 00 00 00 00 00 00 00 00 00  .._@............
    backtrace (crc abf63fca):
      __kmalloc_cache_noprof+0x2e2/0x650
      alloc_rmp_segment_desc+0xdf/0x250
      setup_contiguous_rmptable+0xb0/0xd0
      setup_rmptable+0x13/0x60
      snp_rmptable_init+0x45/0xd0
      iommu_snp_enable+0x77/0xb0
      state_next+0x184/0xed0
      iommu_go_to_state+0x3a/0x90
      pci_iommu_init+0x32/0x50

The descriptor is still in use: get_raw_rmpentry() reads it on every RMP
lookup. Its only reference lives in rmp_segment_table[], and
alloc_rmp_segment_table() takes that table from the page allocator.
kmemleak does not scan page allocator memory, so it never sees the
reference, and mark these segments as leaked when they are not.

Register the table with kmemleak, so it is scanned like any other
object.

kmemleak_alloc() registers a block of memory with kmemleak, so kmemleak
scans it and counts pointers into it, do it with rmp_segment_table.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
 arch/x86/virt/svm/sev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index bd70c4d0b774a3..751ccbdfeba98d 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -20,6 +20,7 @@
 #include <linux/amd-iommu.h>
 #include <linux/nospec.h>
 #include <linux/workqueue.h>
+#include <linux/kmemleak.h>
 
 #include <asm/sev.h>
 #include <asm/processor.h>
@@ -361,6 +362,7 @@ static void __init free_rmp_segment_table(void)
 		kfree(desc);
 	}
 
+	kmemleak_free(rmp_segment_table);
 	free_page((unsigned long)rmp_segment_table);
 
 	rmp_segment_table = NULL;
@@ -376,6 +378,7 @@ static bool __init alloc_rmp_segment_table(void)
 		return false;
 
 	rmp_segment_table = page_address(page);
+	kmemleak_alloc(rmp_segment_table, RST_SIZE, 1, GFP_KERNEL);
 
 	return true;
 }

---
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
change-id: 20261102-sev-rmp-kmemleak-053969ac2126

Best regards,
--  
Breno Leitao <leitao@debian.org>

Re: [PATCH] x86/sev: Fix kmemleak false positive for the RMP segment descriptors

[Dave Hansen]

On 11/2/26 08:49, Breno Leitao wrote:
> Register the table with kmemleak, so it is scanned like any other
> object.
> 
> kmemleak_alloc() registers a block of memory with kmemleak, so kmemleak
> scans it and counts pointers into it, do it with rmp_segment_table.

Why don't we just kmalloc() the thing?

Re: [PATCH] x86/sev: Fix kmemleak false positive for the RMP segment descriptors

[Breno Leitao]

On Mon, Nov 02, 2026 at 12:48:16PM -0800, Dave Hansen wrote:
> On 11/2/26 08:49, Breno Leitao wrote:
> > Register the table with kmemleak, so it is scanned like any other
> > object.
> > 
> > kmemleak_alloc() registers a block of memory with kmemleak, so kmemleak
> > scans it and counts pointers into it, do it with rmp_segment_table.
> 
> Why don't we just kmalloc() the thing?

That would do the work as well, if this is an option.

Re: [PATCH] x86/sev: Fix kmemleak false positive for the RMP segment descriptors

[Dave Hansen]

On 11/2/26 14:30, Breno Leitao wrote:
> On Mon, Nov 02, 2026 at 12:48:16PM -0800, Dave Hansen wrote:
>> On 11/2/26 08:49, Breno Leitao wrote:
>>> Register the table with kmemleak, so it is scanned like any other
>>> object.
>>>
>>> kmemleak_alloc() registers a block of memory with kmemleak, so kmemleak
>>> scans it and counts pointers into it, do it with rmp_segment_table.
>> Why don't we just kmalloc() the thing?
> That would do the work as well, if this is an option.

I don't see a reason it needs to be allocated directly by the page
allocator. My friendly LLM agrees with me. kmalloc(PAGE_SIZE) aligns to
page boundaries and has for years.

BTW, there's almost no reason to use the page allocator directly these days.