GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel LIO iblock: missing PR handler checks let PERSISTENT RESERVE OUT NULL-deref the kernel

CVE-2026-80691Kernel, userspace & hypervisorcurated

Impact

iblock_execute_pr_out() gated PRO_PREEMPT, PRO_PREEMPT_AND_ABORT and PRO_RELEASE on the presence of ops->pr_clear rather than on the hook each command actually calls, so a backing device that implements only part of the persistent-reservation op set lets an unimplemented function pointer be dereferenced as NULL. The result is an oops in the storage target's I/O path, which on a LIO export means the node serving the LUNs goes down and every initiator attached to it loses its block devices at once. For a GPU fleet that boots or checkpoints off iSCSI/FC LUNs from a shared target, that is a fleet-wide stall rather than a single-node incident. The kernel CNA rates this network-reachable with no privileges, consistent with the command arriving from any initiator allowed to talk to the target.

Who can reach it

Any SCSI initiator that can reach an exported LIO LUN over iSCSI, FC, SRP or iSER and send a PERSISTENT RESERVE OUT command. No host login on the target is needed; only whatever authentication the transport itself enforces.

What to do

Take the fixed stable kernel from the linked commits and reboot the storage target nodes; there is no module-reload path for an in-tree target fix that is safe while LUNs are exported. Until then, restrict which initiators may log in to the target (ACLs, transport-level auth, management-network isolation) so untrusted hosts cannot issue PR OUT commands. The kernel record names no fixed release number beyond the stable commits themselves.

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.