iommufd: Avoid locking internal accesses during unmap
- 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.50, 7.2.4
- 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
Summary
In the Linux kernel, the following vulnerability has been resolved: iommufd: Avoid locking internal accesses during unmap iommufd_access_notify_unmap() skips internal accesses because they do not have an external unmap callback to invoke. However, the current test calls iommufd_lock_obj() before checking whether the access is internal. If iommufd_lock_obj() succeeds, the loop then sees the internal access and continues, bypassing the matching iommufd_put_object() used by the normal unmap path. This leaks the object reference taken by iommufd_lock_obj(). Check for internal accesses first so skipped entries are never locked.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 27b77ea5feaa8fcf385ea99ce757982b0ac9d1f0 · fixed in 436189ee4bb2c7c993b945d68570dd38c3e4349e; From 27b77ea5feaa8fcf385ea99ce757982b0ac9d1f0 · fixed in 50a66a63d1c841ae6b28a4551f642c1bba4c9529; From 27b77ea5feaa8fcf385ea99ce757982b0ac9d1f0 · fixed in 0dbcdf4473a614adbd732d567c9b39ac0e040e0c
- Linux Linux
6.17
- KernelLinux
From 6.17.0 · fixed in 6.18.50; From 6.19.0 · fixed in 7.2.4