CVE-2026-63889

What it actually does

This flaw is an adjacent-network Linux kernel vulnerability in the generic Fibre Channel transport FPIN handling path used by initiators such as lpfc and qla2xxx. A malformed Fabric Performance Impact Notification Extended Link Service frame can set the on-wire pname_count field to a value, such as 256, that overflows an 8-bit loop counter. Because the count was not clamped to the validated descriptor body length, the kernel can enter a non-returning loop while walking the FPIN pname list. The practical effect is denial of service: CPU lockup, stalled Fibre Channel processing, hung storage I/O, degraded initiator availability, and possible kernel watchdog resets or crashes. This is not exploitable through normal IP networking or local userspace; the attacker must be able to inject Fibre Channel fabric traffic.

Why it matters to the business

Systems using affected Linux kernels as Fibre Channel initiators can be forced into storage disruption by a malicious or compromised device on the same Fibre Channel fabric. The highest-risk environments are SAN-connected virtualization hosts, database servers, clustered applications, and storage-heavy platforms where loss of FC connectivity can cascade into application outages, failovers, data-access interruptions, or emergency reboots. Although the issue is not listed in CISA KEV, has low EPSS at this time, and has no reported mature public exploit, the impact is operationally significant because exploitation requires only fabric-level access once an attacker is positioned on or controls part of the SAN.

How an attack unfolds

An attacker first obtains the ability to transmit Fibre Channel fabric traffic to a Linux initiator, for example by compromising a Fibre Channel switch, fabric controller, management plane, or a same-zone N_Port in a fabric that allows source spoofing. The attacker then crafts an FPIN ELS frame containing a Link-Integrity or Peer-Congestion descriptor with a pname_count value that exceeds what the vulnerable parser can safely iterate, notably a count that causes the 8-bit walker counter to wrap. When an lpfc or qla2xxx-backed Linux initiator receives the frame, the generic FC transport validates the outer descriptor but does not correctly bound the pname_count against the descriptor body. The kernel enters an effectively infinite loop while processing the FPIN pname list. This can pin CPU execution in kernel context, block storage event handling, cause I/O timeouts, trigger soft lockup or RCU stall warnings, and potentially require node reboot or failover to restore service.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the fix for the FC transport FPIN pname walker: the counter is widened to u32 and pname_count is clamped to the number of entries that fit within the validated descriptor body. Because no exact package versions were provided, use the fixed kernel builds published by the relevant Linux distribution, appliance vendor, hypervisor vendor, or hardware platform vendor. Prioritize SAN-connected systems using Emulex/Broadcom lpfc or Marvell/QLogic qla2xxx drivers. If immediate patching is not possible, reduce exposure by tightening Fibre Channel zoning, disabling unnecessary same-zone initiator-to-initiator communication, enforcing switch/fabric controls that prevent source spoofing, restricting fabric management access, monitoring or filtering anomalous FPIN ELS traffic where supported, and isolating untrusted or less-managed N_Ports from critical initiators. Operational mitigations should be treated as compensating controls, not substitutes for the kernel fix.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or vendor build includes the FC transport FPIN pname_count fix, not merely that a patched package is installed on disk. Reboot into the fixed kernel where required. Inventory hosts for Fibre Channel HBAs and loaded drivers using commands such as lsmod, modinfo lpfc, modinfo qla2xxx, systool -c fc_host, lspci, and distribution package tooling. Validate that SAN-connected Linux initiators are no longer running vulnerable kernel streams according to vendor advisories. Where safe and authorized in a lab, regression testing can involve sending malformed FPIN frames to confirm the host rejects or safely bounds the descriptor rather than hanging; do not test malformed fabric traffic in production. Also validate compensating controls by reviewing zoning, switch port security, fabric authentication or management ACLs, and any controls that prevent same-zone spoofing or unauthorized ELS injection.

Typical attack path

1. Gain the ability to inject Fibre Channel traffic into the target fabric, such as through a compromised switch, fabric controller, or same-zone N_Port with spoofing capability.
2. Identify Linux Fibre Channel initiators using affected kernel code paths, particularly hosts using lpfc or qla2xxx drivers.
3. Craft a malformed FPIN ELS frame with a Link-Integrity or Peer-Congestion descriptor and an unsafe pname_count value such as 256.
4. Deliver the FPIN frame to the target initiator over the Fibre Channel fabric.
5. Trigger the vulnerable generic FC transport pname walker, causing the loop counter to wrap and the kernel processing path not to return.
6. Observe storage I/O stalls, host CPU lockup symptoms, kernel watchdog alerts, service failover, crash, or reboot.

How to detect it

Look for evidence of exploitation across both host and Fibre Channel fabric telemetry. On Linux hosts, collect kernel logs, persistent journal entries, crash dumps, vmcores, kdump output, and monitoring events around the time of storage disruption. Search for soft lockups, RCU stalls, hung tasks, kernel watchdog messages, storage I/O timeouts, SCSI error handling, repeated lpfc or qla2xxx resets, and stack traces referencing Fibre Channel transport or FPIN handling. On SAN infrastructure, review switch and fabric-controller logs for unusual or repeated FPIN ELS frames, malformed Link-Integrity or Peer-Congestion FPIN descriptors, unexpected ELS traffic from end devices, source-port anomalies, same-zone initiator-to-initiator traffic, and any evidence of N_Port source spoofing. Correlate host hangs with fabric events and administrative activity on switches. If packet/fabric capture tooling is available, inspect FPIN frames for a pname_count value inconsistent with the descriptor length, especially pname_count 256. Because this vulnerability causes a denial-of-service condition rather than a conventional file drop or command execution, durable host artifacts may be limited to kernel/fabric logs, crash dumps, and switch telemetry.

• watchdog: BUG: soft lockup
• BUG: soft lockup - CPU
• rcu: INFO: rcu_sched detected stalls
• rcu: INFO: rcu_preempt detected stalls
• INFO: task blocked for more than
• hung_task_timeout_secs
• blocked for more than 120 seconds
• kernel: lpfc
• kernel: qla2xxx
• kernel: scsi_transport_fc
• kernel: fc_host
• FPIN
• Fabric Performance Impact Notification
• Link-Integrity FPIN
• Peer-Congestion FPIN
• pname_count=256
• ELS FPIN
• SCSI error handler
• rejecting I/O to offline device
• blk_update_request: I/O error
• Buffer I/O error on dev
• qla2xxx_abort_command
• qla2xxx_eh_abort
• lpfc_abort_handler
• lpfc_sli_issue_abort_iotag

What your security team should do

• Identify all Linux systems connected to Fibre Channel fabrics, especially hosts using lpfc or qla2xxx drivers, and map them to kernel versions and vendor support status.
• Prioritize patching of production SAN initiators that support critical workloads, clustered platforms, hypervisors, databases, or shared storage services.
• Obtain fixed kernel builds from the operating system or appliance vendor and schedule reboots where required to activate the patched kernel.
• Review Fibre Channel zoning and switch security controls to ensure untrusted N_Ports cannot inject traffic toward critical initiators or spoof fabric sources.
• Harden SAN management planes, including switch administrative access, firmware currency, MFA where available, management network isolation, and audit logging.
• Monitor kernel logs and SAN switch telemetry for abnormal FPIN ELS activity, soft lockups, RCU stalls, storage I/O timeouts, and repeated lpfc or qla2xxx resets.
• Prepare operational runbooks for isolating a suspected malicious fabric port, collecting switch and host logs, and failing over or rebooting impacted hosts safely.
• Track vendor advisories because fixed package names and backport versions vary across distributions and appliance kernels.