GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel iSCSI target: login payload can fill the buffer with no NUL, so CHAP parsing reads past the slab

CVSS 9.1CVE-2026-90011Kernel, userspace & hypervisorcurated

Impact

login->req_buf is allocated at exactly MAX_KEY_VALUE_PAIRS (8192) bytes and the length check uses '>', so a payload of 8189-8192 bytes fills it completely with no room for a terminator. The buffer is then consumed as a C string: kstrdup(), strstr() and strlen_semi() have no length bound, and convert_null_to_semi() rewrites embedded NULs to ';', so parsing walks into adjacent slab memory. This is reachable by an unauthenticated initiator against a portal configured for CHAP - when authentication is not required the AuthMethod is rewritten to None and the CHAP path is never entered. A Linux host exporting iSCSI LUNs to a GPU fleet is therefore attackable by anything that can open a TCP session to the portal. The fix allocates one extra zeroed byte.

Who can reach it

Network, unauthenticated - anyone who can reach the iSCSI portal (typically the storage VLAN) on a target configured to require CHAP. Targets that do not require authentication do not reach the vulnerable path.

What to do

Update to a stable kernel with the linked commits and reboot the target hosts; on an active storage target that means failing over or scheduling downtime for the LUNs it serves. Until then, restrict portal reachability to the storage network and known initiator addresses. No fixed release numbers appear in the record.

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.