GPU VulnDB

Database/NVIDIA / GPU stack

Linux drm/xe: NULL dereference when freeing a devcoredump snapshot that was never populated

UnscoredCVE-2026-97519NVIDIA / GPU stackcurated

Impact

In xe_devcoredump_snapshot_free() the snapshot's gt pointer can be NULL if cleanup runs without a prior capture, and xe_guc_capture_put_matched_nodes() was called on it unguarded; xe_devcoredump_free() likewise called cancel_work_sync() on work that is only queued once a coredump is captured. Either path is a kernel NULL dereference, so the effect is an oops on the node. On an Intel Data Center GPU host this is a crash-and-reboot, not a tenant escape: the trigger is the driver's own error-reporting teardown, which a tenant does not drive directly. The record gives no CVSS score, and it does not describe any way to reach the path on demand.

Who can reach it

Local and indirect: the path runs during xe devcoredump teardown, typically after a GPU error or on driver unload. No authenticated remote or tenant-facing vector is described.

What to do

Take a stable kernel with the IS_ERR_OR_NULL and coredump->captured guards (two stable commits listed) at your next kernel update and reboot the node. Low urgency for a headless fleet unless you are already chasing xe coredump oopses. No vendor advisory or fixed version is in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-97519https://git.kernel.org/stable/c/12ef528d78adc8ea4e7e3db594f3bcac327e79fahttps://git.kernel.org/stable/c/f5c3144f783f91d74b4fae84fb8bd7a4edf001f8

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.