CVE-2026-89514: scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock
In the Linux kernel, the following vulnerability has been resolved:
scsi: fnic: Use GFPATOMIC for VLAN alloc under spinlock
fnicfcoeprocessvlanresp() allocates a VLAN descriptor with kzallocobj() (default GFPKERNEL) while holding vlanslock via spinlockirqsave(). GFPKERNEL may sleep, which is not allowed in this atomic context and can trigger a sleeping-from-invalid-context warning or deadlock.
Pass GFPATOMIC so the allocation is safe under the IRQ-safe spinlock.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In scsi/fnic, change the VLAN descriptor allocation done by fnic_fcoe_process_vlan_resp() (kzalloc_obj()) to use GFP_ATOMIC so the allocation is safe in atomic/IRQ-safe spinlock context while holding vlans_lock.
Linux kernel (scsi: fnic) GFP allocation flag in fnic_fcoe_process_vlan_resp() for VLAN descriptor = GFP_ATOMIC (instead of default GFP_KERNEL)
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems running the Linux kernel FNIC SCSI/FCoE driver are exposed when fnic_fcoe_process_vlan_resp() handles a VLAN response and allocates a VLAN descriptor while holding the IRQ-safe vlans_lock spinlock.
What conditions are needed to trigger the problem?
The affected code path must process a VLAN response, causing kzalloc_obj() to use its default GFP_KERNEL allocation mode while the vlans_lock spinlock is held. GFP_KERNEL can sleep, which is invalid in this atomic context and may produce a warning or deadlock.
What is the available remediation?
Apply the resolved change that passes GFP_ATOMIC for the VLAN descriptor allocation in fnic_fcoe_process_vlan_resp(). This makes the allocation safe while the IRQ-safe spinlock is held.