CVE-2026-43414

What it actually does

This flaw is a double-free/use-after-free condition in the Linux kernel qla2xxx SCSI Fibre Channel driver. In an error path inside qla24xx_els_dcmd_iocb(), the driver releases a reference-counted SCSI/Fibre Channel port object and frees the associated fcport structure through qla2x00_els_dcmd_sp_free(); the same object can then be freed again after kref_put() completes. Releasing the same kernel object twice can corrupt kernel heap metadata or leave stale pointers behind. Depending on timing, allocator state, kernel hardening, and attacker control over subsequent allocations, the impact can range from kernel panic and host denial of service to potential kernel-mode memory corruption and privilege escalation/code execution. Systems without the qla2xxx driver loaded, without affected QLogic/Marvell Fibre Channel hardware, or not using the vulnerable kernel code path are not exposed to this specific driver flaw.

Why it matters to the business

Affected Linux systems using qla2xxx-supported Fibre Channel host bus adapters may be at risk of storage disruption, host crashes, and broader compromise if the kernel memory corruption can be weaponized. For organizations that depend on Fibre Channel SAN connectivity, exploitation or accidental triggering could interrupt access to shared storage, affect virtualized workloads, databases, backup systems, or clustered services, and require emergency host reboots or kernel upgrades. The CVSS score is critical, but current public exploit maturity is reported as none, EPSS is low, and the issue is not listed in CISA KEV, so prioritization should be highest for production systems with QLogic/Marvell Fibre Channel adapters and the qla2xxx module present or loaded.

How an attack unfolds

An attacker would need a way to reach and influence the vulnerable qla2xxx Fibre Channel/SCSI driver path. In a plausible attack, the adversary first identifies Linux hosts using QLogic/Marvell Fibre Channel HBAs with the qla2xxx driver. They then cause an Extended Link Service direct-command operation to enter the vulnerable qla24xx_els_dcmd_iocb() error path. When the error-handling routine unwinds, the driver releases the reference-counted service packet and frees the associated fcport object. Because the surrounding code attempts to free that fcport again after the reference release, the same kernel allocation is released twice. The immediate result may be a kernel oops, panic, or storage driver failure. With sufficient heap shaping and reliability work, an attacker may attempt to turn the double free into controlled kernel memory corruption, potentially obtaining kernel-level execution or tampering with kernel data structures. There is no indication from the provided data that public weaponized exploitation is currently available, and exploitation likely depends heavily on Fibre Channel topology, driver state, kernel version, and allocator hardening.

How to fix it

Apply a Linux kernel update that includes the upstream qla2xxx fix for the fcport double-free issue. Because no exact fixed package versions were provided, obtain corrected kernel packages from the relevant Linux distribution or appliance vendor and verify that their advisory explicitly references the qla2xxx fcport double-free fix or CVE-2026-43414. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the host continues running the old kernel. Where immediate patching is not possible, reduce exposure by limiting access to Fibre Channel fabrics, restricting untrusted initiators/targets/zones, disabling or unloading qla2xxx only where the hardware is not required, and migrating critical workloads away from exposed hosts until maintenance can be completed. Do not unload storage drivers on systems actively booting from or using SAN storage unless a safe maintenance procedure is in place.

How to confirm the fix worked

Confirm whether the system is exposed by checking for qla2xxx hardware and driver usage, for example with lsmod, modinfo, lspci, systool, or distribution inventory tooling. Validate remediation by confirming the host is running the vendor-fixed kernel after reboot with uname -a and package-manager queries, and by checking the distribution advisory or kernel changelog for the qla2xxx fcport double-free fix. Confirm that the qla2xxx module version or running kernel build corresponds to the fixed vendor release. For systems where qla2xxx is not loaded and no compatible Fibre Channel adapter is present, document non-exposure. After patching, monitor kernel logs during normal SAN operations for qla2xxx errors, kernel oops messages, or Fibre Channel link instability to ensure the environment is stable.

Typical attack path

1. Identify Linux systems using qla2xxx-supported QLogic/Marvell Fibre Channel adapters or with the qla2xxx kernel module loaded.
2. Gain the ability to interact with the relevant Fibre Channel/SCSI communication path or otherwise trigger qla2xxx ELS direct-command behavior.
3. Induce an error condition in qla24xx_els_dcmd_iocb() that causes qla2x00_sp_release() and qla2x00_els_dcmd_sp_free() to run.
4. Trigger the second free of the same fcport object after the reference-counted release path has already freed it.
5. Cause kernel heap corruption, typically resulting in a kernel oops, panic, qla2xxx driver instability, or host/storage outage.
6. Optionally attempt heap grooming and follow-on exploitation to convert the memory corruption primitive into kernel-level code execution or privilege escalation.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, system journals, crash dumps, and SAN/fabric telemetry for qla2xxx driver errors followed by kernel oops, BUG, slab allocator warnings, refcount warnings, panic events, or unexpected reboots. Useful log sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, kdump/vmcore artifacts, hypervisor or BMC reset logs, and Fibre Channel switch logs showing unusual link resets, ELS activity, RSCNs, or repeated target/initiator disruptions around the time of host instability. Look for memory corruption symptoms mentioning qla2xxx, qla24xx_els_dcmd_iocb, qla2x00_els_dcmd_sp_free, qla2x00_sp_release, qla2x00_free_fcport, double free, use-after-free, slab corruption, or kernel BUG messages. Because exploitation may only appear as a crash or storage outage, correlate host kernel events with fabric events and application/storage I/O failures. There are no reliable network-only IOCs for this vulnerability from the provided information; detection is primarily behavioral and forensic.

• qla2xxx
• qla24xx_els_dcmd_iocb
• qla2x00_els_dcmd_sp_free
• qla2x00_sp_release
• qla2x00_free_fcport
• fcport double free
• double free
• use-after-free
• kernel BUG
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• KASAN: use-after-free
• KASAN: double-free
• KFENCE: use-after-free
• slab corruption
• corrupted list
• kernel panic
• Oops:
• Call Trace:
• qla2xxx [
• scsi: qla2xxx

What your security team should do

• Prioritize inventory of Linux hosts with QLogic/Marvell Fibre Channel HBAs or the qla2xxx kernel module loaded.
• Patch and reboot exposed production SAN-connected systems using vendor kernels that include the qla2xxx double-free fix.
• Give highest priority to virtualization hosts, database servers, backup infrastructure, clustered systems, and other workloads dependent on Fibre Channel storage.
• Review Fibre Channel zoning and fabric access controls to ensure only trusted initiators and targets can communicate with exposed hosts.
• If patching is delayed, schedule maintenance windows and consider workload migration or storage-path isolation for critical systems.
• Enable collection of kernel logs, crash dumps, and storage/fabric telemetry from systems using qla2xxx so potential exploitation or instability can be investigated.
• Track vendor advisories for exact fixed kernel package versions because fixed_versions were not provided in the input.
• Do not rely on EPSS alone for prioritization; despite low current exploitation probability, kernel memory corruption in a storage driver can have high operational impact.