GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mpi3mr: reset/task-management race dereferences an invalid reply queue ID and crashes the host

CVSS 7.8CVE-2025-37861Kernel, userspace & hypervisorcurated

Impact

The mpi3mr driver lets a task-management thread walk reply queues while the controller reset thread is tearing them down. The reset path stores a sentinel queue ID (0xFFFF) that the other thread then uses as an index, reaching unallocated memory and panicking the host. On a GPU node this is a storage-controller-induced kernel panic: every running job on the box dies and the node comes back only after a full boot. The trigger is a controller reset racing with in-flight I/O, not attacker-supplied input, so treat this as a reliability and availability defect rather than a privilege-escalation path; NVD's 7.8 local vector reflects the generic kernel template, not a demonstrated local-root exploit. Nodes that do not use Broadcom tri-mode HBAs do not load this driver at all.

Who can reach it

No network path. Requires the mpi3mr driver to be in use and a controller reset to coincide with I/O or admin command processing; local users cannot directly request a controller reset without privilege, so the realistic trigger is a storage fault or firmware event.

What to do

Take the stable kernel update carrying the io_admin_reset_sync synchronisation fix (see the linked git commits for the branch-specific backports). Applying it means drain the node and reboot into the patched kernel - the driver cannot be hot-swapped while it owns the boot or data storage controller. No vendor mitigation exists short of the kernel patch; nodes without Broadcom tri-mode HBAs need no action.

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.