CVE-2026-46105

What it actually does

CVE-2026-46105 is a Linux kernel mpt3sas SCSI/NVMe driver flaw where the driver can accept an NVMe Maximum Data Transfer Size reported by HBA firmware that exceeds what the driver’s fixed 4 KB PRP-list buffer can safely represent. Because that buffer can hold at most 512 PRP entries, the practical supported transfer size is 2 MiB. If the block layer issues larger I/O through affected mpt3sas paths, the driver can construct or process an oversized request and trigger a kernel oops. Although classified primarily as denial of service, the CVSS vector indicates local, low-complexity exploitation by a low-privileged user with potential severe impact to confidentiality, integrity, and availability due to kernel-level fault behavior.

Why it matters to the business

Successful exploitation can crash or destabilize Linux systems using affected mpt3sas storage paths, potentially interrupting applications, databases, virtualization hosts, backup systems, or storage-heavy workloads. The operational risk is highest for servers where local users, containers, jobs, or services can generate large block I/O to NVMe devices behind mpt3sas HBAs. This issue is not in CISA KEV, has no known mature public exploit, and has a low EPSS score, so broad internet-driven exploitation is unlikely; however, the impact can still be significant for multi-user or high-availability Linux systems because a local user or compromised workload may be able to trigger a host-level crash.

How an attack unfolds

An attacker first needs local code execution or the ability to run a process that performs block I/O on an affected Linux host using the mpt3sas driver with NVMe devices behind a compatible HBA. The attacker then causes the system to issue I/O requests larger than the driver’s true 2 MiB PRP-list capacity, for example through direct I/O, raw block-device access where permitted, or workload patterns that generate large transfers. If the HBA firmware reports an MDTS larger than the driver can safely handle and the kernel has not applied the fix, the oversized request can reach the mpt3sas path. The mismatch between reported device capability and driver buffer capacity can trigger a kernel oops, causing a system crash, service interruption, or degraded storage availability.

How to fix it

Apply a Linux kernel update that includes the upstream mpt3sas fix limiting max_hw_sectors to the smaller of the device-reported MDTS and the driver’s 2 MiB request-size limit. Because no exact fixed package versions were provided, use the latest security kernel available from the relevant Linux distribution or kernel vendor and confirm the vendor advisory references this mpt3sas/NVMe request-size fix. Reboot into the updated kernel after installation. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting raw block-device permissions, isolating untrusted workloads from affected storage hosts, avoiding oversized direct I/O workloads on affected devices, and prioritizing maintenance windows for systems using mpt3sas with NVMe drives behind HBAs.

How to confirm the fix worked

Confirm the system is running a kernel version or vendor backport that includes the mpt3sas change to cap NVMe request size at 2 MiB. Verify loaded driver exposure with commands such as `lsmod | grep mpt3sas`, `lspci -nn | grep -i -E 'sas|scsi|broadcom|lsi|avago'`, and storage inventory tools showing NVMe devices behind the HBA. Check `/sys/block/*/queue/max_hw_sectors_kb` for affected block devices and confirm the advertised maximum does not exceed 2048 KB for the relevant mpt3sas NVMe paths. Review kernel logs after reboot to ensure the updated kernel is active and that no new mpt3sas-related oops messages appear under representative storage workloads. Avoid destructive validation on production systems; use controlled test hosts and non-critical devices if reproducing large-I/O behavior.

Typical attack path

1. Obtain local access to a vulnerable Linux system, such as through a shell, compromised service account, container escape scenario, batch job, or other low-privileged execution path.
2. Identify that the system uses the mpt3sas driver and NVMe storage behind an HBA whose reported maximum transfer size can exceed the driver’s 2 MiB PRP-list limit.
3. Generate large block I/O requests that exceed 2 MiB through available device, filesystem, or application-level access paths.
4. Cause the vulnerable driver to process an oversized NVMe request rather than limiting it to the supported driver maximum.
5. Trigger a kernel oops, leading to host instability, service disruption, or denial of service.

How to detect it

To determine whether this issue may already have been exploited or triggered, review kernel and system logs for mpt3sas-related errors, NVMe request failures, kernel oops traces, panic events, and unexpected reboots. Primary log sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, persistent systemd journals, crash dump directories, kdump/vmcore artifacts, and hardware management logs that record host resets. Correlate any kernel oops mentioning `mpt3sas`, `NVMe`, `PRP`, `blk`, `scsi`, or request-size handling with local user sessions, batch jobs, container activity, storage benchmarks, backup jobs, or applications issuing large I/O shortly before the crash. Look for repeated crash patterns on hosts with the mpt3sas module loaded and block queue limits above 2048 KB. Because exploitation is local and may resemble a workload-induced kernel fault, there may be no network IOC; detection should focus on host logs, crash dumps, process accounting, audit logs for block-device access, and timing correlation between large I/O activity and kernel oops events.

• mpt3sas
• kernel oops
• Oops:
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• blk_update_request
• I/O error
• nvme
• PRP
• max_hw_sectors
• max_hw_sectors_kb
• /sys/block/*/queue/max_hw_sectors_kb
• /var/crash/
• /var/lib/systemd/coredump/
• /proc/modules
• mpt3sas.ko

What your security team should do

• Prioritize patching Linux servers that load the mpt3sas driver and host critical storage, virtualization, database, backup, or multi-user workloads.
• Inventory systems using mpt3sas and NVMe devices behind SAS/SCSI HBAs, then map them to installed kernel versions and vendor advisory status.
• Restrict local and workload-level access that can generate raw or unusually large block I/O until affected hosts are patched.
• Monitor kernel logs for mpt3sas, NVMe, block-layer, and kernel oops messages, especially on systems with recent crashes or unexplained reboots.
• Ensure reboot orchestration is included in remediation plans, because kernel package installation alone does not protect systems until the fixed kernel is running.
• Treat suspicious crashes following large local I/O activity as possible exploitation or abuse, even though there is currently no KEV listing, known ransomware use, or mature public exploit.