GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux nvme-pci: slab out-of-bounds read in nvme_dbbuf_set during controller reset

CVSS 7.1CVE-2026-43449Kernel, userspace & hypervisorcurated

Impact

nvme_dbbuf_set() looped past dev->online_queues, reading one entry beyond the doorbell-buffer array allocated at probe time; KASAN catches it as a slab out-of-bounds read reached from nvme_reset_work. The path runs on NVMe controller reset, which happens on probe, on error recovery and on device hotplug - all of which occur on their own on GPU nodes with local NVMe scratch, so no attacker action is needed to hit it. The practical risk is a host crash or corrupted doorbell state on the node's local storage path, which on a GPU host means an unplanned loss of every job resident on it. The record documents a read, not a write, and names no privilege-escalation path.

Who can reach it

No network or tenant path. The faulty loop runs in the kernel's nvme-reset workqueue, so it is reached by the host itself during NVMe probe, reset or error recovery; local access only, and triggering it deliberately needs control over the NVMe device's reset behaviour.

What to do

Update to a stable kernel with the corrected loop bound; commits are linked across 5.10 through 7.0 branches. This requires a kernel update and a reboot of each node with NVMe devices - in practice all of them - so schedule it as a rolling drain and reboot. No mitigation or configuration workaround is described.

References

Related entries

All Kernel, userspace & hypervisor 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.