accel/qaic: zero-length DMA transfer request from userspace causes a general protection fault

CVSS 7.8CVE-2025-40172NVIDIA / GPU stackcurated

Impact

The qaic driver for Qualcomm Cloud AI accelerators returned early from find_and_map_user_pages() when a DMA transfer request carried length 0, or when the device asked for transfer continuation after all bytes had already moved, without allocating the scatter-gather table or filling the dma_xfer struct. encode_addr_size_pairs() then accessed the absent sgt and took a general protection fault. Any tenant holding the accelerator device node can crash the host kernel with a crafted zero-length transfer, which on a shared inference node means every job on the box dies and the node needs a reboot that cannot be scheduled politely.

Who can reach it

Local user with access to the qaic accelerator character device - in practice any tenant whose container or job has the accelerator passed through. Authentication to the node is required; no network path. The second trigger (continuation after full transfer) needs the device itself to misbehave.

What to do

Update to a stable kernel that returns -EINVAL for zero-length ALPs and for continuation after full transfer (four commits in the record), then reboot each node carrying qaic accelerators. If you cannot patch promptly, the only mitigation is to stop exposing the accelerator device to untrusted workloads, which takes the node out of service for its purpose.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-40172 https://git.kernel.org/stable/c/11f08c30a3e4157305ba692f1d44cca5fc9a8fca https://git.kernel.org/stable/c/1ab9733d14cc9987cc5dcd1f0ad1f416e302e2e6 https://git.kernel.org/stable/c/48b1d42286bfef7628b1d6c8c28d4e456c90f725

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.