CVE-2026-98144: accel/amdxdna: put the chained BO when its mapping fails
In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: put the chained BO when its mapping fails
amdxdnacmdseterror() 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 aie2cmdlistfillslot() has already called amdxdnacmdgetop() on that BO and amdxdnagemvmap() 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 amdxdnagemgetobj() returning an object this cannot map, since primeimport() types every import AMDXDNABOSHARE.
Affected Software
Event History
Frequently Asked Questions
Who can realistically trigger the leaked reference?
Ordinary use does not reach this path. An attacker needs userspace control of the relevant buffer-object handle after command submission so the handle can be closed and recycled.
What conditions are needed to make the mapping fail?
After submitting the command chain, the original handle must be closed and reused for an imported dma-buf whose exporter does not implement vmap. The replacement import is typed as AMDXDNA_BO_SHARE, causing the later object lookup to return an object that cannot be mapped.
How can a system be affected if the command already mapped the original buffer?
The command submission path has already cached the original buffer's mapped address. The vulnerable error path performs a new lookup by the userspace-recyclable handle; when mapping of that newly resolved object fails, it returns without dropping the reference it acquired.