CVE-2025-68371

What it actually does

Use-after-free in the smartpqi SCSI driver caused by a race between the abort handler scheduling a LUN reset work item and concurrent device removal via sdev_destroy(), allowing the reset handler to access freed device resources after the device is removed from the controller's list.

Why it matters to the business

Kernel instability or crashes on systems using smartpqi storage controllers can lead to unplanned downtime for storage-dependent workloads, with potential for local privilege escalation if the flaw is triggered in a way that corrupts kernel memory.

How an attack unfolds

An attacker with local access triggers concurrent SCSI device removal and abort operations; the abort handler schedules a pending LUN reset that executes after sdev_destroy() has freed the device, resulting in access to invalid memory.

How to fix it

Update the Linux kernel to a version containing commit 7dfa5a5516ec3c6b9b6c22ee18f0eb2df3f38ef2 or later; for Chainguard packages update chainctl and docker-credential-cgr to 0.2.59-r0 or newer. Ensure the device presence check, pending TMF work cancellation, and mutex-protected freeing are present in the smartpqi driver.

How to confirm the fix worked

Verify the applied kernel commit or package version matches the fixed revisions; inspect the smartpqi reset handler for the device list presence check and sdev_destroy() for mutex-protected freeing and work cancellation.

Typical attack path

1. Obtain local access on a system using the smartpqi driver
2. Trigger SCSI device removal via sdev_destroy() while an abort handler is active
3. Schedule a LUN reset work item concurrently with removal
4. Allow the reset handler to execute after device resources are freed
5. Exploit resulting use-after-free for denial of service or code execution

How to detect it

Review kernel logs and dmesg for smartpqi driver warnings or oops messages referencing LUN resets or device removal races; correlate with SCSI subsystem events showing concurrent aborts and removals.

What your security team should do

• Prioritize kernel updates on all systems using smartpqi controllers within the next patching cycle
• Monitor vendor advisories for backported fixes in distribution kernels
• Test updated kernels in staging environments before broad deployment
• Review storage subsystem logs for unexpected device removal events during the transition