CVE-2023-52515

What it actually does

Calling scsi_done() from srp_abort() after scmd_eh_abort_handler triggers a use-after-free because the SCSI error handler may subsequently invoke scsi_queue_insert, scsi_finish_command, or scsi_eh_scmd_add on the same command structure.

Why it matters to the business

Linux systems using RDMA/SRP storage can experience kernel crashes, data corruption, or potential privilege escalation, leading to downtime and requiring urgent kernel updates across server fleets.

How an attack unfolds

An attacker with the ability to issue SCSI commands over an SRP/RDMA connection triggers an abort handler; the flawed srp_abort path then calls scsi_done on a command the SCSI mid-layer still owns, resulting in a use-after-free that can be leveraged for memory corruption or code execution.

How to fix it

Upgrade the Linux kernel to a version containing commit 26788a5b48d9d5cd3283d777d238631c8cd7495a or later; rebuild and reboot affected systems; apply vendor-supplied kernel packages that backport the fix.

How to confirm the fix worked

Confirm the running kernel contains commit 26788a5b48d9d5cd3283d777d238631c8cd7495a via git log or uname; test SRP abort paths in a lab environment to verify scsi_done is no longer called from srp_abort; monitor for absence of use-after-free crashes in kernel logs after upgrade.

Typical attack path

1. Obtain access to issue SRP commands on a vulnerable Linux host
2. Craft or time SCSI I/O operations to force an abort via scmd_eh_abort_handler
3. Trigger srp_abort which incorrectly invokes scsi_done()
4. Exploit the resulting use-after-free for memory corruption or privilege escalation

How to detect it

Search kernel logs and crash dumps for use-after-free signatures involving srp_abort or scsi_done; inspect audit logs for unusual SCSI abort activity on SRP devices; review system call traces leading to RDMA abort handlers.

What your security team should do

• Prioritize patching kernel packages on all systems exposing RDMA/SRP interfaces
• Inventory hosts using the srp module and schedule reboots
• Add kernel version checks to vulnerability scanning policies
• Review SRP/RDMA configurations for least-privilege access