ptp: kvm: x86: Leak clock_pair page if changing its encryption fails

In a confidential guest, kvm_arch_ptp_init() shares the clock_pair page with the host using set_memory_decrypted(), and kvm_arch_ptp_exit() makes it private again with set_memory_encrypted() before freeing it.

The untrusted host can make either call fail and leave the page shared. Both paths still free the page: the init error path with __free_page(), and kvm_arch_ptp_exit() after only a WARN_ON(). The page allocator can then hand a page the host can still access to an unrelated user.

Leak the page in both cases instead, as was done for the same situation in commit b9fa16949d18 ("dma-direct: Leak pages on dma_set_decrypted() failure") and commit 03f5a999adba ("Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails").

---
This was found with a static analysis tool from ongoing, not yet published research, and confirmed by code inspection. Compile-tested only (x86_64 with KVM_GUEST, AMD_MEM_ENCRYPT and INTEL_TDX_GUEST, W=1); I do not have a confidential guest to test it on.

 drivers/ptp/ptp_kvm_x86.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

index 6cea4fe39bcfe..811758bd8b0de 100644
@@ -36,7 +36,7 @@ int kvm_arch_ptp_init(void)
 		clock_pair = page_address(p);
 		ret = set_memory_decrypted((unsigned long)clock_pair, 1);
 		if (ret) {
-			__free_page(p);
+			/* The page may be left shared, so leak it. */
 			clock_pair = NULL;
 			goto nofree;
 		}

@@ -68,8 +68,9 @@ int kvm_arch_ptp_init(void)
 void kvm_arch_ptp_exit(void)
 {
 	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
-		WARN_ON(set_memory_encrypted((unsigned long)clock_pair, 1));
-		free_page((unsigned long)clock_pair);
+		/* Leak the page if it cannot be made private again. */
+		if (!WARN_ON(set_memory_encrypted((unsigned long)clock_pair, 1)))
+			free_page((unsigned long)clock_pair);
 		clock_pair = NULL;
 	}
 }

base-commit: 0822d2fe38262e8b55c5ea55c970022bca8dd2a9

2.43.0