Bug 2420418 (CVE-2025-40343)

Summary:	CVE-2025-40343 kernel: nvmet-fc: avoid scheduling association deletion twice
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	Keywords:	Security
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel's NVMe over Fibre Channel (nvmet-fc) target subsystem. When forcefully shutting down a port through the configfs interface, both nvmet_port_del_ctrls() and nvmet_disable_port() schedule association deletions. Due to insufficient synchronization, the same work item can be scheduled twice, leading to a double-free condition where resources are freed by the first work item and then the same work item attempts to free them again. This can cause memory corruption, system crashes, or potentially be exploited for privilege escalation.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2025-12-09 05:02:07 UTC

In the Linux kernel, the following vulnerability has been resolved:

nvmet-fc: avoid scheduling association deletion twice

When forcefully shutting down a port via the configfs interface,
nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and
then nvmet_disable_port(). Both functions will eventually schedule all
remaining associations for deletion.

The current implementation checks whether an association is about to be
removed, but only after the work item has already been scheduled. As a
result, it is possible for the first scheduled work item to free all
resources, and then for the same work item to be scheduled again for
deletion.

Because the association list is an RCU list, it is not possible to take
a lock and remove the list entry directly, so it cannot be looked up
again. Instead, a flag (terminating) must be used to determine whether
the association is already in the process of being deleted.

Comment 1 Alexander B 2025-12-09 13:20:14 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2025120912-CVE-2025-40343-dbb0@gregkh/T