CVE-2026-45872

What it actually does

This is a Linux kernel memory-leak flaw in the smartpqi SCSI storage driver. When pqi_report_phys_luns() encounters certain error paths, such as an unsupported report format or a failed allocation for a 16-byte WWID list, it returns without freeing the previously allocated rpl_list buffer. Repeatedly triggering those paths can consume kernel memory over time, potentially causing memory pressure, degraded I/O behavior, process termination by the OOM killer, or a system crash/reboot. The flaw does not provide confidentiality or integrity impact; its primary impact is local denial of service on systems using the affected smartpqi driver.

Why it matters to the business

Organizations running affected Linux kernels on systems with Microchip/Adaptec SmartPQI-compatible storage controllers may face unexpected server instability or outages if a local user or compromised local process can repeatedly trigger the vulnerable driver path. The operational risk is highest for virtualization hosts, storage-heavy servers, database platforms, backup infrastructure, and other systems where storage availability is business-critical. This issue is not currently listed in CISA KEV, has no known public exploitation maturity, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local denial-of-service flaws remain important on multi-user systems and environments where attackers may already have a foothold.

How an attack unfolds

An attacker first needs local access to an affected Linux system where the smartpqi kernel driver is present and handling compatible storage hardware. From that foothold, the attacker attempts to reach code paths that cause pqi_report_phys_luns() to request physical LUN reporting and then fail before normal cleanup occurs. If the request produces an unsupported data format or forces a downstream allocation failure, the function exits without freeing rpl_list. By repeating the triggering action, the attacker can gradually leak kernel memory. Over time, this can create system-wide memory pressure, disrupt storage-related operations, trigger OOM conditions, or cause the host to become unstable or unavailable.

How to fix it

Upgrade the Linux kernel to a vendor-provided version that includes the smartpqi fix ensuring rpl_list is freed on all pqi_report_phys_luns() failure paths. No exact fixed package versions were provided in the input, so use the relevant distribution advisory for Red Hat, Ubuntu, Debian, SUSE, Oracle Linux, Amazon Linux, or the applicable appliance/vendor kernel. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting users and services that can issue low-level storage/SCSI operations, removing or blacklisting the smartpqi module only where the hardware is not required, and prioritizing patching for multi-user or storage-critical hosts. Do not disable the driver on systems that depend on it for boot or storage access without vendor validation and recovery planning.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version matches a distribution release that includes the smartpqi memory-leak fix. Check whether the smartpqi module is loaded using standard host inventory methods such as lsmod, modinfo, or /sys/module/smartpqi. Validate that package management shows the patched kernel installed and that the host has rebooted into that kernel, since kernel updates are not effective until the fixed kernel is running. For high-assurance validation, review the vendor kernel changelog or source package to confirm the pqi_report_phys_luns() cleanup change is present. After patching, monitor for recurring kernel memory growth, OOM events, and smartpqi-related errors under normal storage operations.

Typical attack path

1. Gain local access to an affected Linux system, either as a legitimate low-privileged user or through a previously compromised process.
2. Confirm the system is using the smartpqi SCSI storage driver and compatible storage hardware.
3. Trigger the driver path that invokes pqi_report_phys_luns() under conditions that cause an early error return.
4. Repeat the triggering action to accumulate unreleased kernel memory allocations.
5. Cause kernel memory pressure, degraded storage behavior, OOM events, service disruption, or host instability.

How to detect it

There are no public, reliable exploit-specific indicators for this vulnerability based on the available information. Detection should focus on signs of attempted or successful denial of service on systems using the smartpqi driver. Review kernel logs, system journals, crash dumps, and monitoring telemetry for abnormal kernel memory growth, repeated OOM killer events, smartpqi driver errors, storage enumeration anomalies, or unexplained host instability. Useful log sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, audit logs for suspicious local command execution, EDR process telemetry, and hardware/storage controller management logs. Investigate repeated low-level SCSI/storage probing activity by non-administrative users, especially when correlated with rising kernel slab or unreclaimable memory and subsequent OOM or reboot events. Because this is a memory leak rather than code execution, absence of a dropped file or network callback does not rule out exploitation.

What your security team should do

• Inventory Linux systems using the smartpqi driver and prioritize those with critical storage roles, multi-user access, or exposed local execution paths.
• Apply the vendor-fixed kernel update and reboot into the patched kernel during the next appropriate maintenance window, prioritizing storage-critical and shared systems.
• If patching is delayed, restrict local interactive access and limit processes/users that can perform low-level storage or SCSI operations.
• Monitor affected hosts for kernel memory pressure, OOM killer activity, unexplained reboots, and smartpqi-related kernel log messages.
• Confirm that vulnerability scanners and asset inventories distinguish between installed patched kernels and the currently running kernel.
• Track Linux distribution advisories for exact fixed versions because no fixed versions were provided in the CVE input.