GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel - iSCSI TCP initiator, drivers/scsi/libiscsi_tcp.c: TENANT ISOLATION: The iSCSI initiator receives PDU

CVE-2026-74556Kernel, userspace & hypervisorlibiscsi_tcp SCSI Response data segment overflowopen-iscsi initiator conn->data overflowcurated

Impact

TENANT ISOLATION: The iSCSI initiator receives PDU data segments into a fixed 8192-byte conn->data buffer. The login, text, reject and async-event paths all check the DataSegmentLength against that size, but the SCSI Command Response path copies sense and response data in without the same check. The only remaining bound is the initiator's advertised MaxRecvDataSegmentLength, which open-iscsi defaults to 262144 - so a target returning a SCSI Response with a data segment between 8193 and 262144 bytes overflows the buffer by up to 250 KB. Target-to-initiator again: one compromised or rogue iSCSI target achieves kernel memory corruption on every compute node that mounts from it.

Who can reach it

The attacker controls an iSCSI target the victim connects to, or can inject into the TCP session, and returns a SCSI Command Response with an oversized data segment. Because open-iscsi's default MaxRecvDataSegmentLength is far above the buffer size, the vulnerable window is wide in stock configurations rather than requiring unusual tuning.

What to do

Host reboot / kernel upgrade on all iSCSI initiator nodes - the compute fleet, so plan a rolling drain. Immediate config mitigation that closes the window without a reboot: set MaxRecvDataSegmentLength to 8192 or below in /etc/iscsi/iscsid.conf and reconnect sessions, which caps the receive length at the buffer size. Also verify targets are authenticated (mutual CHAP) so a rogue target cannot attract sessions.

References

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.