CVE-2026-90008: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-90008 Overview

CVE-2026-90008 is a heap buffer overflow in the Linux kernel megaraid_sas SCSI driver. The flaw resides in megasas_make_prp_nvme(), which builds a command's Physical Region Page (PRP) list inside cmd->sg_frame, a DMA pool buffer sized to instance->max_chain_frame_sz. The loop populating the PRP list runs until the entire transfer is described and never checks the buffer bound. Following the block layer default increase to 4 MiB in commit 9b8b84879d4a, transfers on drives reporting a large Maximum Data Transfer Size (MDTS) can require 1025 PRP entries, exceeding the 512-entry capacity of a 4 KiB chain frame.

Critical Impact
The out-of-bounds write can trigger a kernel page fault or silently corrupt neighbouring in-flight commands' PRP lists, leading to denial of service or memory corruption on hosts using MegaRAID controllers with NVMe drives.

Affected Products

Linux kernel versions containing commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") through the fix commits
Systems using the megaraid_sas SCSI driver with attached NVMe drives reporting a large MDTS
Server and storage platforms built on Broadcom MegaRAID controllers

Discovery Timeline

2026-09-16 - CVE-2026-90008 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-90008

Vulnerability Analysis

The megasas_make_prp_nvme() function constructs a PRP list to describe a SCSI-to-NVMe command's data transfer. Each PRP entry covers one NVMe page of the transfer, with an additional entry per page of the buffer reserved for the chain pointer. The list is written into cmd->sg_frame, a DMA pool allocation sized to instance->max_chain_frame_sz, commonly 4 KiB (512 entries).

The kernel derives max_hw_sectors directly from the MDTS reported by the NVMe drive firmware. Historically, the block layer default of 1280 KiB required only 320 PRP entries, safely fitting within the chain frame. After commit 9b8b84879d4a raised BLK_DEF_MAX_SECTORS_CAP to 4 MiB, a full transfer on a drive with a large MDTS requires 1025 entries, which overruns the 4 KiB frame by a full page.

When the page following the frame is unmapped, the write faults with unable to handle page fault for address in megasas_build_and_issue_cmd_fusion. When that page is mapped, the overrun silently corrupts an adjacent DMA pool entry, typically another in-flight command's PRP list, producing data corruption or system instability.

Root Cause

The loop that populates the PRP list lacks a bounds check against max_chain_frame_sz. The driver trusts the firmware-reported MDTS and the block layer's max_hw_sectors to keep the transfer within the chain frame, an invariant broken by the block layer default increase. This is an out-of-bounds write [CWE-787] rooted in missing input validation on transfer size.

Attack Vector

Exploitation requires local privileges sufficient to issue large I/O against a SCSI device backed by the megaraid_sas driver on an NVMe drive with a large MDTS. Standard filesystem workloads that generate 4 MiB block-layer transfers are enough to reach the vulnerable code path. Successful triggering results in kernel memory corruption or a page fault panic, giving high impact to confidentiality, integrity, and availability of the affected host.

No public proof-of-concept exploit is available. The vulnerability is described in prose only; see the upstream fix commits 4bb34769, 4dd118d0, and af8c2737 for the patch mechanics.

Detection Methods for CVE-2026-90008

Indicators of Compromise

Kernel log messages containing page boundary ptr_sgl followed by BUG: unable to handle page fault for address originating in megasas_build_and_issue_cmd_fusion
Unexplained SCSI command failures, I/O errors, or filesystem corruption on volumes served by the megaraid_sas driver
Kernel oops or panic traces referencing megasas_make_prp_nvme or megaraid_sas module frames

Detection Strategies

Inventory hosts running vulnerable kernel builds that load the megaraid_sas module with attached NVMe backends and compare against the fixed commit hashes
Query NVMe controller MDTS values on affected hosts to identify drives capable of triggering transfers larger than the chain frame can describe
Correlate storage stack crashes with concurrent large sequential I/O workloads to isolate the driver as the fault source

Monitoring Recommendations

Forward dmesg and /var/log/kern.log to a central log platform and alert on megaraid_sas fault signatures
Track kernel version drift across the fleet so unpatched hosts with the vulnerable driver are visible in asset inventory
Monitor storage subsystem health metrics for retry storms or unexpected command aborts that may indicate silent PRP list corruption

How to Mitigate CVE-2026-90008

Immediate Actions Required

Apply the upstream kernel fix that caps max_hw_sectors at what the chain frame can describe, less one page for non-page-aligned transfers
Prioritize patching servers using MegaRAID controllers fronting NVMe drives, especially where firmware reports a large MDTS
Reboot into the patched kernel; the driver limit is applied at initialization and cannot be adjusted at runtime without a reload

Patch Information

The fix is available in the following upstream commits: Kernel Git Commit 4bb3476, Kernel Git Commit 4dd118d, and Kernel Git Commit af8c273. The patch derives the transfer limit from max_chain_frame_sz rather than hardcoding a value, mirroring the earlier mpt3sas fix in commit 04631f55afc5. Distribution vendors are backporting the change to supported stable branches.

Workarounds

Lower /sys/block/<dev>/queue/max_sectors_kb on affected NVMe-backed SCSI devices to a value that keeps required PRP entries below 512 as a stopgap until the kernel is patched
Restrict local user access and reduce workloads that generate maximum-size sequential transfers on unpatched hosts
Where feasible, replace megaraid_sas passthrough with direct NVMe attach so the vulnerable code path is not exercised

bash

# Temporary per-device cap: reduce max transfer size to keep PRP list within the chain frame
# Replace sdX with the affected device name
echo 1024 > /sys/block/sdX/queue/max_sectors_kb

# Verify the applied value
cat /sys/block/sdX/queue/max_sectors_kb