accel/amdxdna: put the chained BO when its mapping fails
- 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.19, 7.2.7
- 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: accel/amdxdna: put the chained BO when its mapping fails amdxdna_cmd_set_error() looks up the first BO of a command chain, which takes a reference, and drops it at the end of the function. The mapping of that BO is established in between, and the failure path returns without the put, so the reference is leaked. Ordinary use does not reach it. The chain has been submitted before any of this runs, so aie2_cmdlist_fill_slot() has already called amdxdna_cmd_get_op() on that BO and amdxdna_gem_vmap() has cached its address. What makes it reachable is that the BO is resolved again by handle here, and the handle is userspace's to recycle: closing it after submission and importing a dma-buf whose exporter implements no vmap onto the same id leaves amdxdna_gem_get_obj() returning an object this cannot map, since prime_import() types every import AMDXDNA_BO_SHARE.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From d76856beb4a4a6c42244054cd780c00f2d33de4e · fixed in eb90cb257e0792ac11f0347254bad3fc72417db6; From d76856beb4a4a6c42244054cd780c00f2d33de4e · fixed in 7e33ba3a1d48c2d20ed270dec9d2d08332585c8e; From 6.18.57 · fixed in 6.19
- Linux Linux
7.1
- KernelLinux
From 7.1.0 · fixed in 7.2.7