CVE-2026-23306: Linux Kernel Use-After-Free Vulnerability

CVE-2026-23306 Overview

A use-after-free vulnerability has been identified in the Linux kernel's pm8001 SCSI driver, specifically within the pm8001_queue_command() function. This memory corruption issue was introduced by commit e29c47fe8946 ("scsi: pm8001: Simplify pm8001_task_exec()") which refactored the command queuing logic but inadvertently created a double-free scenario when handling PHY down or device gone states.

The vulnerability occurs when pm8001_queue_command() returns -ENODEV in response to a PHY down or device gone condition. In this code path, the function updates the task status and calls task_done to signal to the upper layer that the task has been handled, which frees the underlying SAS task. However, by returning -ENODEV, the calling function sas_ata_qc_issue() in libsas assumes the task wasn't handled by the Low-Level Device Driver (LLDD) and proceeds to clean up and free the task again, resulting in a double-free condition.

Critical Impact

This use-after-free vulnerability in the Linux kernel SCSI subsystem can lead to kernel memory corruption, system instability, and potential privilege escalation on systems utilizing PMC-Sierra pm8001 SAS/SATA Host Bus Adapters.

Affected Products

• Linux kernel with pm8001 SCSI driver enabled
• Systems utilizing PMC-Sierra pm8001 SAS/SATA Host Bus Adapters
• Enterprise storage servers and data center infrastructure using affected kernel versions

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23306 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23306

Vulnerability Analysis

The vulnerability resides in the error handling logic of the pm8001_queue_command() function within the pm8001 SCSI driver. When a SAS task needs to be executed but the target PHY is down or the device has been removed, the function attempts to gracefully handle this situation by completing the task with an error status and notifying the upper layer via the task_done callback.

The core issue lies in the interaction between the pm8001 driver and the libsas layer. When task_done is called, the SAS task structure is freed by the upper layer. The function then returns -ENODEV to indicate the device is unavailable. However, the libsas sas_ata_qc_issue() function interprets this return value as an indication that the LLDD did not handle or queue the task, leading it to perform its own cleanup routine which attempts to free the already-freed task structure.

This double-free condition corrupts kernel memory allocator metadata, which can lead to system crashes, kernel panics, or potentially be exploited for privilege escalation by a sophisticated attacker who can control the contents of the freed memory regions.

Root Cause

The root cause is an incorrect return value in the error handling path of pm8001_queue_command(). When the function handles a SAS task by calling task_done (which frees the task), it should return 0 to indicate to the caller that the task has been successfully handled. Instead, returning -ENODEV signals to libsas that the task was not processed, causing libsas to attempt cleanup on an already-freed memory structure.

The fix is straightforward: change the return value from -ENODEV to 0 in the PHY down/device gone code path, correctly communicating to the upper layer that the task has been handled by the LLDD.

Attack Vector

The attack vector involves triggering a device disconnection or PHY down event while SAS/SATA I/O operations are in flight. An attacker with physical access to the storage infrastructure could manipulate SAS connections, or a malicious privileged user could potentially craft sequences of I/O operations and device state changes to trigger the race condition.

The vulnerability is primarily exploitable in the following scenarios:

1. During hot-plug/hot-unplug events of SAS devices
2. When a device experiences a link failure during active I/O
3. Through coordinated timing attacks on device state transitions

Detection Methods for CVE-2026-23306

Indicators of Compromise

• Kernel panic or oops messages referencing pm8001_queue_command or sas_ata_qc_issue functions
• KASAN (Kernel Address Sanitizer) reports indicating use-after-free in SCSI subsystem
• Unexpected system crashes during SAS/SATA device hot-plug operations
• Memory corruption warnings in kernel logs related to slab allocator

Detection Strategies

• Enable KASAN (Kernel Address Sanitizer) to detect memory corruption issues during testing
• Monitor for kernel oops or panics with backtraces involving pm8001 driver functions
• Implement kernel log monitoring for SCSI driver errors and memory allocation failures
• Deploy crash dump analysis to identify signatures of the double-free condition

Monitoring Recommendations

• Configure continuous monitoring of kernel logs for SCSI subsystem anomalies
• Set up automated alerts for kernel panics and system crashes on affected servers
• Enable kernel debugging features in non-production environments to detect memory corruption early
• Monitor storage controller events and device state transitions for abnormal patterns

How to Mitigate CVE-2026-23306

Immediate Actions Required

• Apply the kernel patches from the official Linux kernel stable tree immediately
• Schedule maintenance windows to reboot systems with patched kernels
• Limit physical access to SAS infrastructure to reduce exploitation risk
• Consider temporarily disabling hot-plug functionality on critical systems if patching is delayed

Patch Information

The Linux kernel development team has released patches to address this vulnerability across multiple kernel versions. The fix modifies pm8001_queue_command() to return 0 instead of -ENODEV when the task is handled via task_done, correctly signaling to libsas that the task cleanup has already been performed.

Official patches are available in the following kernel commits:

• Kernel Git Commit 227ff4af00abc
• Kernel Git Commit 38353c26db28
• Kernel Git Commit 824a7672e354
• Kernel Git Commit 8b00427317ba
• Kernel Git Commit c5dc39f8ae05
• Kernel Git Commit ebbb852ffbc9

Workarounds

• Avoid hot-plug operations on SAS devices until patches are applied
• Implement strict change control procedures for storage infrastructure modifications
• Consider using alternative SCSI drivers if available for the hardware
• Enable kernel memory debugging options to detect exploitation attempts

The definitive fix requires modifying the return value in the error path. Organizations running affected kernels should update their systems using their distribution's package manager or by compiling a patched kernel from source:

# Check current kernel version
uname -r

# Update kernel on Debian/Ubuntu systems
sudo apt update && sudo apt upgrade linux-image-$(uname -r)

# Update kernel on RHEL/CentOS systems
sudo yum update kernel

# Reboot to apply the patched kernel
sudo reboot