Bug 2482654 (CVE-2026-46135)

Summary:	CVE-2026-46135 kernel: nvmet-tcp: fix race between ICReq handling and queue teardown
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	CC:	rhel-process-autobot, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
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 TCP (nvmet-tcp) implementation. A race condition exists between the handling of an Initialization Connection Request (ICReq) and the teardown of a queue. A remote attacker, by sending an ICReq and immediately closing the connection, could trigger a double free vulnerability. This could lead to a denial of service (DoS) due to memory corruption.	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 2026-05-28 11:07:53 UTC

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

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmet_tcp_handle_icreq() updates queue->state after sending an
Initialization Connection Response (ICResp), but it does so without
serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request
(ICReq) and immediately closes the connection, target-side teardown
may start in softirq context before io_work drains the already
buffered ICReq. In that case, nvmet_tcp_schedule_release_queue()
sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue
reference under state_lock.

If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can
still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the
DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and
allows a later socket state change to re-enter teardown and issue a
second kref_put() on an already released queue.

The ICResp send failure path has the same problem. If teardown has
already moved the queue to DISCONNECTING, a send error can still
overwrite the state with NVMET_TCP_Q_FAILED, again reopening the
window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with
state_lock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather
than propagating it as a transport error like -ECONNRESET. Keep
nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before
honoring that sentinel so receive-side parsing stays quiesced until the
existing release path completes.

Comment 1 Keith Grant 2026-05-28 17:14:59 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026052818-CVE-2026-46135-6f53@gregkh/T

Comment 4 errata-xmlrpc 2026-06-19 16:29:46 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:27354 https://access.redhat.com/errata/RHSA-2026:27354

Comment 5 errata-xmlrpc 2026-06-19 16:51:18 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:27353 https://access.redhat.com/errata/RHSA-2026:27353

Comment 6 errata-xmlrpc 2026-06-22 08:29:05 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:27789 https://access.redhat.com/errata/RHSA-2026:27789

Comment 7 errata-xmlrpc 2026-06-25 22:13:29 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:30129 https://access.redhat.com/errata/RHSA-2026:30129

Comment 8 errata-xmlrpc 2026-07-06 14:26:15 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions

Via RHSA-2026:35904 https://access.redhat.com/errata/RHSA-2026:35904

Comment 9 errata-xmlrpc 2026-07-07 05:34:00 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions

Via RHSA-2026:36073 https://access.redhat.com/errata/RHSA-2026:36073

Comment 10 errata-xmlrpc 2026-07-13 12:50:44 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.6 Extended Update Support

Via RHSA-2026:38902 https://access.redhat.com/errata/RHSA-2026:38902

Comment 11 errata-xmlrpc 2026-07-14 16:41:19 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10.0 Extended Update Support

Via RHSA-2026:39371 https://access.redhat.com/errata/RHSA-2026:39371

Comment 12 errata-xmlrpc 2026-07-15 15:54:28 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support
  Red Hat Enterprise Linux 8.6 Extended Update Support Long-Life Add-On

Via RHSA-2026:40068 https://access.redhat.com/errata/RHSA-2026:40068

Comment 13 errata-xmlrpc 2026-07-22 06:23:41 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions

Via RHSA-2026:43231 https://access.redhat.com/errata/RHSA-2026:43231

Comment 14 errata-xmlrpc 2026-07-29 01:06:34 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support
  Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On

Via RHSA-2026:47633 https://access.redhat.com/errata/RHSA-2026:47633

Comment 15 errata-xmlrpc 2026-07-29 13:30:48 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.8 Update Services for SAP Solutions
  Red Hat Enterprise Linux 8.8 Telecommunications Update Service

Via RHSA-2026:47869 https://access.redhat.com/errata/RHSA-2026:47869