CVE-2026-43473

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel mpi3mr SCSI storage controller driver. During error handling or resource cleanup, the driver may attempt to access request or reply queue memory after queue creation failed and the associated memory was freed or left NULL. A local user able to trigger the affected driver path can cause a kernel crash or panic. The impact is availability only; the provided CVSS vector indicates no confidentiality or integrity impact, local attack vector, low attack complexity, and low privileges required.

Why it matters to the business

Systems using affected Linux kernel versions with the mpi3mr storage driver may crash unexpectedly, causing downtime for applications, storage services, virtualization hosts, or infrastructure nodes that depend on those systems. Because this is not currently listed in CISA KEV, has very low EPSS, and has no known mature public exploit, broad internet-scale exploitation is unlikely; however, the operational impact can still be significant on systems where local users, workloads, or tenants can interact with the affected kernel and storage stack.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel with the mpi3mr driver present and in use or reachable. The attacker then attempts to trigger driver initialization, reset, failure, or cleanup paths where reply or request queue allocation fails. When the driver handles the failure, vulnerable versions may free queue memory and then continue to access or clear it without verifying that the queue pointers are valid. That invalid memory access can result in a kernel oops, panic, or system crash, producing a denial of service. There is no indication from the supplied data that this flaw enables privilege escalation, data theft, or remote code execution.

How to fix it

Update the Linux kernel to a vendor-supported version that includes the mpi3mr fix adding NULL pointer checks before accessing request and reply queues during cleanup. No exact fixed package versions were provided, so use the relevant Linux distribution or kernel vendor advisory to identify the corrected kernel build. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the old kernel remains active. Where the driver is not required, consider disabling or blacklisting the mpi3mr module, but only after confirming the system does not depend on it for boot or storage access. As compensating controls, restrict local shell access, limit untrusted workloads on affected hosts, and prioritize patching systems where local users or multi-tenant workloads can trigger kernel or storage-driver behavior.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the mpi3mr driver and whether the active kernel build predates the vendor fix. Use distribution package metadata, kernel changelogs, or source review to verify that NULL checks were added around request and reply queue cleanup in the mpi3mr driver. Validate remediation by rebooting into the corrected kernel and confirming the active kernel version with standard OS tooling. On systems where mpi3mr is unnecessary, confirm the module is not loaded and is blacklisted where appropriate. Review system logs after remediation for absence of new mpi3mr-related kernel oops, NULL pointer dereference, or panic events during storage-controller reset or cleanup activity.

Typical attack path

1. Obtain local low-privileged access to a Linux system running an affected kernel.
2. Confirm the mpi3mr storage controller driver is present, loaded, or reachable through hardware and kernel paths.
3. Induce or wait for a driver reset, initialization failure, queue creation failure, or resource-cleanup condition affecting request or reply queues.
4. Trigger the vulnerable cleanup path where freed or NULL queue memory is accessed.
5. Cause a kernel oops or panic, resulting in system unavailability until recovery or reboot.

How to detect it

Because this issue causes denial of service rather than persistent compromise, there may be no durable post-exploitation artifact beyond crash evidence. Review kernel logs, system journal entries, console logs, crash dumps, kdump/vmcore data, and out-of-band management event logs for mpi3mr-related failures followed by kernel oops or panic events. Focus on messages indicating NULL pointer dereference, use-after-free-like cleanup failures, queue reset or cleanup activity, SCSI driver reset activity, or unexpected reboots. Correlate crash times with local user sessions, job execution, container activity, storage-controller events, and repeated attempts to trigger driver resets or resource exhaustion. A single crash may also be caused by hardware or ordinary driver failure, so look for repetition, timing correlation with user activity, and recurring mpi3mr queue cleanup failures.

• mpi3mr
• scsi: mpi3mr
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• general protection fault
• request queue
• reply queue
• kdump
• vmcore
• /var/crash
• /var/log/kern.log
• /var/log/messages
• journalctl -k

What your security team should do

• Inventory Linux systems running affected kernels, especially storage, virtualization, database, and infrastructure hosts where a crash would have high operational impact.
• Prioritize patching systems with the mpi3mr driver loaded or hardware requiring that driver, particularly where local users or untrusted workloads are present.
• Apply the vendor-fixed kernel and reboot into it; verify the running kernel, not just installed packages.
• If mpi3mr is not required, assess whether the module can be safely disabled or blacklisted without impacting boot or storage availability.
• Restrict local access and reduce untrusted workload execution on affected systems until patched.
• Monitor kernel logs for mpi3mr-related crashes, NULL pointer dereferences, oops messages, and panic events.
• Treat unexplained crashes on affected systems as potential denial-of-service activity and preserve logs for forensic review.