CVE-2026-89514

What it actually does

The Linux fnic FCoE driver allocates a VLAN descriptor with a sleeping GFP_KERNEL allocation while holding an IRQ-safe spinlock (vlans_lock via spin_lock_irqsave) in fnic_fcoe_process_vlan_resp(). Sleeping in that atomic context can produce a sleeping-from-invalid-context warning, stall the CPU, deadlock the lock, or hang or panic the kernel. Impact is availability (local denial of service / instability), not confidentiality or integrity. No privilege escalation or remote code execution is indicated.

Why it matters to the business

Hosts using the fnic SCSI/FCoE driver (typically Cisco VIC Fibre Channel over Ethernet adapters) can suffer unexpected kernel warnings, storage-path disruption, hangs, or reboots, interrupting SAN-backed workloads. Likelihood of active exploitation is low: EPSS is about 0.002 and unchanged over 30 days, the CVE is not in CISA KEV, ransomware use is not reported, and exploit maturity is none. Treat as a stability/patch-hygiene issue rather than an emergency internet-facing incident, but prioritize systems whose storage depends on fnic.

How an attack unfolds

This is a local kernel correctness bug, not a remote network exploit. An attacker or faulty peer who can cause the host to process an FCoE VLAN discovery/response while the fnic driver holds vlans_lock can force kzalloc_obj() with GFP_KERNEL in atomic context. That may log a kernel warning or deadlock/hang the machine, denying service. No named threat actors, KEV campaigns, or public exploits are associated. Exploitation requires a system running the unpatched fnic path and the ability to trigger FCoE VLAN response handling; it does not by itself yield code execution or data theft.

How to fix it

Apply the upstream Linux kernel fix that passes GFP_ATOMIC (instead of the default GFP_KERNEL) for the VLAN descriptor allocation in fnic_fcoe_process_vlan_resp() so the allocation is valid under the IRQ-safe spinlock. Deploy the patched kernel from your distribution or vendor as soon as it is available, then reboot into the new kernel. If a packaged fix is not yet listed, track scsi/fnic patches for this change and avoid relying on workarounds that leave the sleeping allocation in place. Systems without the fnic driver loaded are not affected.

How to confirm the fix worked

Confirm the running kernel includes the GFP_ATOMIC allocation in fnic_fcoe_process_vlan_resp() (distribution changelog, vendor advisory, or kernel source/config for scsi/fnic). Verify fnic is loaded only where required (lsmod/sysfs). After patching and reboot, reproduce FCoE VLAN processing in a maintenance window and confirm dmesg/journalctl show no sleeping-from-invalid-context warnings attributed to fnic. Unpatched kernels may log BUG: sleeping function called from invalid context during VLAN response handling.

Typical attack path

1. Identify a Linux host using the fnic driver for FCoE/SAN connectivity.
2. Obtain local access or influence FCoE VLAN discovery/response traffic that the driver will process.
3. Cause fnic_fcoe_process_vlan_resp() to allocate a VLAN descriptor while vlans_lock is held with spin_lock_irqsave.
4. Trigger GFP_KERNEL allocation in atomic/IRQ-safe context, producing a sleeping-from-invalid-context condition.
5. Resulting kernel warning, deadlock, hang, or panic disrupts the host and attached Fibre Channel storage.

How to detect it

This bug leaves kernel-log artifacts rather than network IOCs. Search dmesg, journalctl -k, and crash dumps for sleeping-from-invalid-context or BUG messages whose call trace includes fnic_fcoe_process_vlan_resp, fnic, or vlans_lock around FCoE VLAN processing. Correlate with SAN/FCoE events and unexpected hangs or panics on hosts that load fnic. Absence of those traces does not prove the code path was never hit; presence with an fnic stack strongly suggests the unpatched allocation ran. No public exploit tooling or named actor TTPs are documented.

• BUG: sleeping function called from invalid context
• fnic_fcoe_process_vlan_resp
• vlans_lock
• kzalloc_obj
• scsi_fnic
• fnic

What your security team should do

• Inventory Linux hosts with the fnic module loaded or Cisco VIC FCoE HBAs and schedule kernel updates for those first.
• Apply the vendor/distro kernel that contains the GFP_ATOMIC fnic VLAN allocation fix and reboot.
• Do not treat this as KEV-level or ransomware-driven urgency; EPSS is ~0.002 with no known in-the-wild exploitation.
• Watch kernel logs on unpatched fnic hosts for atomic-sleep warnings during FCoE VLAN events.
• After remediation, confirm the new kernel is running and fnic-related sleeping-in-atomic warnings have stopped.