CVE-2026-53021

What it actually does

This is an integer-overflow flaw in the Linux kernel SCSI target implementation. When processing a SCSI UNMAP command, the kernel checked whether the requested logical block address plus the requested range exceeded the exported device capacity, but did not first verify that the addition itself could not wrap around a 64-bit integer boundary. A crafted UNMAP request from an initiator with access to the target could therefore make an out-of-bounds range appear valid after wraparound. The likely technical consequences are incorrect discard operations, corruption of the exported logical unit, I/O errors, target instability, or denial of service. This should be treated primarily as an integrity and availability issue affecting systems that expose Linux kernel SCSI target/LIO-backed storage to initiators.

Why it matters to the business

Organizations using Linux systems as SCSI/iSCSI/Fibre Channel/FCoE target storage could experience data corruption or disruption if an authorized or compromised initiator sends malicious UNMAP requests. The issue is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, so broad opportunistic exploitation is less likely; however, storage-layer flaws can have high operational impact because they may affect availability and integrity of hosted workloads, virtual disks, databases, backups, or shared storage volumes.

How an attack unfolds

An attacker first needs a path to interact with a vulnerable Linux kernel SCSI target as an initiator, such as access to an exposed iSCSI target, a compromised host already permitted to connect, or control of a tenant/workload that can issue raw SCSI commands to an exported LUN. The attacker then sends a crafted SCSI UNMAP command with a logical block address and range chosen so that the arithmetic LBA + range overflows the 64-bit value used by the kernel bounds check. Because the wrapped value can appear to fall within the device capacity, the request may bypass validation that should reject it. The target then processes an invalid discard range, which can cause unintended storage modification, data loss, I/O failures, or target instability depending on the backing device and kernel behavior. There is no indication from the supplied intelligence that this is a remote code execution vulnerability or that it is being exploited in known campaigns.

How to fix it

Upgrade the Linux kernel to a version that includes the fix for the SCSI target UNMAP overflow check. If distribution-specific fixed versions are not yet identified, use the vendor’s security advisory or stable kernel changelog for the running kernel branch and confirm that the patch for `scsi: target: core: Fix integer overflow in UNMAP bounds check` is included. Prioritize systems using the Linux kernel target subsystem, including LIO/targetcli-backed iSCSI, Fibre Channel, FCoE, or other SCSI target deployments. If immediate patching is not possible, restrict target access to trusted initiators only, remove unnecessary LUN exposure, disable or limit network reachability to storage target ports, segment storage networks, and consider disabling discard/UNMAP support where operationally acceptable. Ensure recent backups or snapshots are available before remediation because exploitation could affect data integrity.

How to confirm the fix worked

Confirm the running kernel version or package build includes the upstream fix for the SCSI target UNMAP overflow check. Validate with the operating system vendor’s advisory, package changelog, or kernel source/package metadata rather than relying only on version strings when using backported enterprise kernels. Inventory whether the host loads or uses Linux SCSI target components such as `target_core_mod`, `iscsi_target_mod`, or related fabric modules. Review target configuration for exported LUNs under configfs and confirm that only expected initiators can access them. After patching, reboot into the fixed kernel if required and verify that the active running kernel is the updated one. Where safe in a test environment, issue boundary-condition UNMAP validation tests and confirm malformed ranges are rejected without I/O errors or target instability.

Typical attack path

1. Identify a Linux kernel SCSI target service, commonly through authorized storage access or exposed iSCSI/target infrastructure.
2. Authenticate or otherwise gain initiator-level access to a LUN that accepts SCSI UNMAP commands.
3. Craft a SCSI UNMAP request where the starting LBA and range cause 64-bit arithmetic wraparound.
4. Send the malformed UNMAP command to the vulnerable target.
5. Rely on the flawed bounds check to accept an invalid range.
6. Trigger unintended discard behavior, storage corruption, I/O errors, or denial of service against the exported device.

How to detect it

Look for evidence that a system acting as a Linux SCSI target received abnormal or boundary-condition UNMAP/discard commands before patching. Useful sources include kernel logs, journald, syslog, storage appliance logs, iSCSI target logs, audit logs for target configuration changes, network captures on storage networks, and initiator-side SCSI command logs if available. Investigate unexplained bursts of UNMAP commands, especially from unexpected initiator IQNs, WWPNs, IP addresses, or hosts that do not normally issue discard operations. Correlate these events with kernel messages about target resets, command failures, I/O errors, block-layer discard failures, filesystem corruption, LUN inconsistencies, or sudden data loss. Also review configuration changes to exported LUNs and initiator ACLs around the time of any storage anomaly. Network-level detection may require protocol-aware decoding of iSCSI or Fibre Channel traffic to identify SCSI UNMAP commands and anomalous LBA/range values; generic logs may not record the exact malformed arithmetic condition. No attacker-specific infrastructure, malware artifact, or campaign IOC is derivable from the provided information.

What your security team should do

• Identify Linux systems acting as SCSI targets, especially iSCSI/LIO/targetcli deployments, and prioritize them over general-purpose Linux servers that do not expose SCSI target functionality.
• Patch affected kernels through the relevant Linux distribution or appliance vendor and verify the fixed kernel is actively running after reboot.
• Restrict SCSI target access to explicitly trusted initiators using network segmentation, ACLs, CHAP or equivalent authentication, and firewall rules.
• Review whether UNMAP/discard support is required for exported LUNs; disable or limit it where business requirements allow until patching is complete.
• Monitor storage-target logs, kernel logs, and initiator activity for abnormal UNMAP/discard behavior, unexplained I/O errors, LUN corruption, or target resets.
• Preserve backups and storage snapshots for critical LUNs before applying changes or investigating suspected exploitation.
• Because this issue is not currently KEV-listed, has low EPSS, and has no known exploit maturity in the provided data, handle as prioritized infrastructure hardening unless the environment exposes SCSI targets to untrusted or multi-tenant initiators.