This CVE (CVSS 7.8) describes a resource leak in the xe GPU driver where xe_svm_init() was made unconditional by commit 9e9787414882, but the corresponding error-path cleanup in xe_svm_fini() remained conditional. When xe_vm_create() fails after the init call succeeds, the partially-initialized vm->svm.gpusvm state leaks instead of being freed. The patch is nine lines moving vm->size = 0 outside the conditional block to satisfy an assert in xe_svm_fini() that checks xe_vm_is_closed() — indicating the authors already knew cleanup expected a specific state, yet the asymmetry still crept in during the refactoring.
The practical severity differs from the CVSS score. The EPSS of 0.00127 reflects that this class of bug — the 'unconditional init, conditional fini' asymmetry — is a well-known genotype in systems code, frequently caught by review and static analysis before weaponization. Unprivileged users can trigger xe_vm_create() failure, but whether repeated failures cause measurable DoS depends on the specific hardware state and driver configuration required for creation to fail. The leak itself is serious because kernel resource leaks accumulate without recovery until reboot.
The more concerning question is whether the partially-initialized vm->svm.gpusvm state introduces a double-free or use-after-free surface if xe_vm_close_and_put() is subsequently called on the leaked object. The assert in xe_svm_fini() exists precisely because partially-initialized state passed to cleanup is dangerous — cleanup routines may operate on inconsistent assumptions about what was allocated. If other driver subsystems hold references to the vm object when cleanup runs wrong, the leak becomes a UAF vector.
For defenders: verify your kernel version includes the fix (check for the moved vm->size = 0 line in xe_svm_init error path). Monitor for xe_vm_create() failures in logs, as repeated failures from unprivileged users could indicate exploitation attempts. The more critical monitoring target is xe_vm_close_and_put() behavior on objects that may have experienced creation failure — any unusual reference count behavior or crash reports mentioning xe_svm_fini warrant investigation. On LTS backports, be aware that the init/fini pairing assumptions may differ across kernel versions, making the partial-state cleanup risk version-dependent.