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.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In fnic_fcoe_process_vlan_resp(), pass GFP_ATOMIC to kzalloc_obj() when allocating the VLAN descriptor while vlans_lock is held via spin_lock_irqsave().
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.