CVE-2026-63890

What it actually does

This is a Linux kernel denial-of-service flaw in the FCoE control-plane parser. A malformed FIP Clear Virtual Link frame containing a non-critical descriptor with a zero descriptor length can cause the FCoE descriptor-walking loop to make no forward progress. On affected Linux FCoE initiators using fcoe, qedf, or bnx2fc paths, this can leave fcoe_ctlr_recv_work stuck indefinitely and prevent subsequent FIP frames from being processed for that controller. The practical technical effect is disruption of FCoE discovery/control-plane handling and possible loss or degradation of Fibre Channel over Ethernet storage connectivity.

Why it matters to the business

An attacker with Layer 2 access to the FCoE control VLAN could disrupt storage connectivity for Linux systems using affected FCoE initiator drivers. In business terms, this can cause application outages, failed I/O, degraded service, or operational incidents tied to unavailable SAN-backed storage. The risk is lower than an Internet-exposed remote code execution issue because exploitation requires local network adjacency to the FCoE VLAN, and the current EPSS score is low with no known KEV listing or ransomware association; however, the impact can still be significant in environments where FCoE supports critical workloads.

How an attack unfolds

An attacker first gains the ability to send Ethernet frames on the same Layer 2 segment as the FCoE control VLAN. The attacker then crafts a FIP Clear Virtual Link control frame with a single descriptor marked as a non-critical descriptor, using a descriptor length of zero. Because vulnerable kernels do not reject that malformed descriptor before walking the descriptor list, the parser advances the cursor by zero bytes and repeatedly processes the same descriptor. This causes the FCoE receive work handler to hang, blocking later FIP control frames for that controller. The attacker does not need credentials or host-level access, but must be able to inject traffic onto the relevant FCoE VLAN.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the fix to reject FIP descriptors whose length is smaller than the descriptor header, including zero-length descriptors. No specific package fixed versions were provided in the input, so remediation should be tracked through vendor kernel advisories for the relevant distribution, storage appliance, hypervisor, or embedded platform. Where immediate patching is not possible, reduce exposure by strictly isolating FCoE control VLANs, preventing untrusted systems from joining FCoE Layer 2 segments, enforcing switch port security, disabling unused FCoE functionality, and removing or blacklisting unused FCoE-related drivers where operationally safe.

How to confirm the fix worked

Confirm that systems no longer run an affected kernel build by checking the vendor advisory or changelog for the FCoE fix that rejects zero-length or undersized FIP descriptors in fcoe_ctlr_recv_clr_vlink(). Validate that FCoE-capable systems are patched through normal kernel package inventory and reboot verification, because kernel fixes generally require booting into the updated kernel. Exposure can be assessed by identifying hosts with FCoE initiator drivers loaded or configured, including fcoe, qedf, and bnx2fc, and by confirming whether those hosts are connected to FCoE VLANs. Network validation should confirm that only trusted ports can transmit FIP traffic on the FCoE control VLAN and that unauthorized Layer 2 injection is blocked.

Typical attack path

1. Obtain Layer 2 adjacency to the FCoE control VLAN or compromise a device that can transmit on that VLAN.
2. Identify Linux systems using FCoE initiator functionality, particularly fcoe, qedf, or bnx2fc-based configurations.
3. Craft a FIP Clear Virtual Link frame using a non-critical descriptor type and a zero descriptor length.
4. Transmit the malformed FIP frame to the affected FCoE control-plane segment.
5. Cause the vulnerable kernel FCoE control receive worker to loop indefinitely and stop processing subsequent FIP frames.
6. Leverage the resulting storage control-plane disruption to cause application errors, storage path instability, or service outage.

How to detect it

Post-exploitation detection should focus on network evidence from the FCoE control VLAN and host evidence of FCoE receive-worker stalls or storage control-plane disruption. Network sensors, packet captures, or switch telemetry should be reviewed for FIP traffic using EtherType 0x8914 with malformed descriptors, especially descriptors whose length field is zero or smaller than the descriptor header and descriptor types in the non-critical range. Host logs may show secondary symptoms rather than a clean exploit log entry, such as FCoE link instability, storage path failures, SCSI timeouts, blocked kernel worker warnings, or hung task reports involving FCoE control functions. Investigators should correlate the first occurrence of storage instability with FIP frames from unexpected source MAC addresses on the FCoE VLAN. Because a single malformed frame may be sufficient, absence of repeated traffic does not rule out exploitation if packet capture was not active at the time.

• EtherType 0x8914
• FIP descriptor length 0
• fip_dlen=0
• fip_dtype=0x80
• FIP_DT_NON_CRITICAL
• fcoe_ctlr_recv_clr_vlink
• fcoe_ctlr_recv_work
• blocked for more than 120 seconds
• INFO: task fcoe
• qedf
• bnx2fc
• FCoE CVL
• Clear Virtual Link

What your security team should do

• Inventory Linux systems that use FCoE initiator functionality or have fcoe, qedf, or bnx2fc drivers loaded.
• Prioritize patching for storage-connected Linux systems supporting critical applications, even though public exploitation maturity and EPSS are currently low.
• Apply the vendor-supplied kernel update containing the FIP descriptor length validation fix and reboot into the updated kernel.
• Restrict FCoE control VLAN access to trusted switch ports and authorized storage/network devices only.
• Monitor FCoE VLANs for malformed FIP traffic, especially FIP frames with zero-length descriptors or non-critical descriptor types combined with invalid lengths.
• Review recent storage path instability, FCoE control-plane errors, application I/O failures, or unexplained hangs for possible correlation with malformed FIP traffic.
• Disable unused FCoE services, interfaces, and kernel modules where they are not required.