Linux kernel qaic: oversized buffer object remaps past the VMA, leaving mappings that survive munmap

CVE-2026-64051NVIDIA / GPU stackcurated

Impact

qaic_gem_object_mmap() called remap_pfn_range() without checking the buffer object's scatter-gather length against the space left in the VMA, so a sufficiently large BO maps past the end of the mapping. munmap() then tears down only the VMA region and leaves the extra mappings behind, giving a use-after-free on pages the kernel considers freed. This only matters on hosts that actually have Qualcomm Cloud AI 100 accelerators and load the qaic driver; nodes without the hardware are not exposed. Where the cards are present and handed to tenants, the device node is the whole boundary - the flaw is reachable from the same ioctl/mmap surface a tenant needs for normal inference work.

Who can reach it

Local user holding an open handle to the qaic accelerator device node - i.e. any tenant whose container is given the Cloud AI 100 device. No additional privilege needed.

What to do

Update to a stable kernel containing the bounds check (commits linked below) or a distro kernel that has backported it. The driver is built into the kernel image path here, so this is a kernel update: drain the node and reboot. If you do not run Cloud AI 100 hardware, confirm the qaic module is not loadable on your image and treat this as not applicable rather than scheduling a window.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-64051 https://git.kernel.org/stable/c/8c795012d0e06b7740e40319b86ff8d2a435098d https://git.kernel.org/stable/c/aa16b2bc0f02709919e2435f531406531e5bcc69

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.