CVE-2026-68298: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()

In the Linux kernel, the following vulnerability has been resolved:

drm/xe/vm: Fix SVM leak on resv obj alloc failure in xevmcreate()

Commit 9e9787414882 ("drm/xe/userptr: replace xehmm with gpusvm") made xesvminit() unconditional in xevmcreate() and extended it to also initialize a "simple" gpusvm state for non-fault-mode VMs. The matching xesvmfini() call in xevmcloseandput() was updated to run unconditionally, but the error unwind path in xevmcreate() was not.

On the drmgpuvmresvobjectalloc() failure path, xesvminit() has already succeeded but xesvmfini() is only called when XEVMFLAGFAULTMODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drmgpusvminit().

For fault-mode VMs, xesvminit() additionally acquires the pagemap owner via drmpagemapacquireowner() and the pagemaps via xesvmgetpagemaps(). Those resources are released by xesvmclose(), not xesvmfini(). On the same error path, xesvmclose() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps.

Fix both leaks:

- Call xesvmfini() unconditionally on the errsvmfini path, matching the unconditional xesvminit() call. Move the vm->size = 0 assignment out of the conditional so the xevmisclosed() assert in xesvmfini() (and xesvmclose()) holds for both modes.

- Call xesvmclose() for fault-mode VMs before xesvmfini(), matching the ordering used in xevmcloseandput().

(cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)