Linux kernel smartpqi: memory leak in pqi_report_phys_luns() error paths on Smart Array controllers

CVSS 5.5CVE-2026-45872Firmware, BMC & network fabriccurated

Impact

pqi_report_phys_luns() returns early on an unsupported RPL data format or a failed rpl_16byte_wwid_list allocation without freeing rpl_list, leaking the buffer each time. smartpqi drives Microchip/HPE Smart Array and Smart HBA controllers, which are the boot and local-NVMe/SAS path on a lot of GPU server SKUs. The leak is bounded by how often LUN reporting is retried, so the practical impact is slow unreclaimable kernel memory growth on nodes whose controller reports an unexpected format - not a crash or a privilege boundary crossing. The commit message notes it was found by static analysis and compile tested only.

Who can reach it

Local and largely not attacker-driven: the path runs during driver LUN rescans, so reaching it needs either a controller returning an unsupported report format or allocation failure under memory pressure. No tenant-reachable trigger is described.

What to do

Pick up the fixed stable kernel (five stable commits linked, consolidating cleanup under an out_free_rpl_list label) and reboot each affected node on the normal kernel cadence. There is no mitigation short of the patch, and nothing here justifies an out-of-band window on its own.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-45872 https://git.kernel.org/stable/c/41b37312bd9722af77ec7817ccf22d7a4880c289 https://git.kernel.org/stable/c/d52e13122d3771f753dd73ae6512fa01f58015cb https://git.kernel.org/stable/c/f471ecfec093e39ef8fd08978413793087daa14d

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.