drm/gem: fix race between change_handle and handle_delete
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.18.35, 7.0.12
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: drm/gem: fix race between change_handle and handle_delete drm_gem_change_handle_ioctl leaves the old handle live in the IDR during the window between spin_unlock(table_lock) and the final spin_lock(table_lock). A concurrent drm_gem_handle_delete on the old handle succeeds in this window, decrements handle_count to 0, and frees the GEM object while the new handle's IDR entry still references it. NULL the old handle's IDR entry before dropping table_lock so that any concurrent GEM_CLOSE on the old handle sees NULL and returns -EINVAL. Restore the old entry on the prime-bookkeeping error path.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 672464dd53231509c9c771110798c56d4660e19e · fixed in 0dfa42cfe4dbe114533480503934f43e33c1e83d; From 61bd96d3e5472c253f9c1ab77608f0c8aaa9d025 · fixed in cde2c9257cbe8463b9dcf7b1075177b72b5fd938; From 5e28b7b94408897e41c63477aabc9e1db439bc8c · fixed in 7164d78559b0ff29931a366a840a9e5dd53d4b7c
- Linux Linux
From 6.18.32 · fixed in 6.18.35; From 7.0.9 · fixed in 7.0.12
- KernelLinux
From 6.18.32 · fixed in 6.18.35; From 7.0.9 · fixed in 7.0.12