All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v5 0/5] IB/isert: fix the device removal use-after-free
@ 2026-11-03 12:59 Yehyeong Lee
  2026-11-03 12:59 ` [PATCH v5 1/5] IB/isert: do not publish connections being released on a second list Yehyeong Lee
                   ` (5 more replies)
  0 siblings, 6 replies; 12+ messages in thread
From: Yehyeong Lee @ 2026-11-03 12:59 UTC (permalink / raw)
  To: Sagi Grimberg, Max Gurtovoy, Jason Gunthorpe, Leon Romanovsky
  Cc: Martin K . Petersen, Mike Christie, linux-rdma, target-devel,
	linux-kernel, Yehyeong Lee

The RDMA_CM_EVENT_DEVICE_REMOVAL callback in ib_isert waits for the
connection it was handed to reach ISER_CONN_DOWN and then frees it, a
use-after-free against isert_connect_release(), and the wait deadlocks
against the handler_mutex rdma_destroy_id() needs.  3/5 moves the teardown
into an ib_client callback, as nvmet-rdma did in f1d4ef7d8883, and gives
every connection one owner.  1/5 and 2/5 are older problems; 4/5 and 5/5
close two holes the walk makes visible.

v4 -> v5

v4: https://lore.kernel.org/r/20261103032924.1073138-1-yhlee@isslab.korea.ac.kr

The critical point on 1/3 was the skipped drain.  v4 checked ownership
first and returned without draining, so a posted login receive could
complete after kfree().  1/5 drains before it takes the connection, the
order mainline already uses.  I did not reproduce the failure: with
isert_free_np() parked inside its take window and a reject arriving on the
connection it held, two runs of v4 and two of v5 both reported nothing.

The high point on 2/3 was isert_accept_np() taking the connection while the
drain ran outside isert_conn->mutex.  2/5 empties isert_conn->node under
isert_np->mutex before it terminates, so only that owner drains; if
accept_np got there first the node is already empty, and the handler
rereads the state under the same lock and hands the connection to iscsi.
That is the same race as the teardown against accept_np below, and I did
not reproduce it either.  The low point, the kdoc, is a Return: line on
isert_conn_terminate() now.

The critical point on 3/3 was ib_destroy_qp() after accept, and iWARP.  v5
has no post-accept error path left to destroy a QP on.  iWARP I could not
measure: a siw portal cannot listen here, because enabling iser adds a
child np at the parent portal's address and siw binds a TCP socket to it.

A high point on 3/3 was the walk against isert_connect_error(), with the
leaked promotion reference.  isert_conn->cm_id was written with no lock, so
the walk could call rdma_disconnect(NULL), and a promoted connection that
errored out leaked a reference.  The owner clears cm_id under
isert_conn->mutex now and 4/5 drops that reference.  A REJ after the RTU is
the cell for both; the INIT-only half I could not open alone, because the
device whose removal opens it must carry the reject.

A high point on 3/3 was the teardown against isert_accept_np().  isert_np
is reference counted now and the teardown runs on a reference taken under
isert_conn_mutex.  Nothing faulted in over forty window entries a run, so
that one is not reproduced.

The last high point on 3/3 was the late isert_device.  5/5 refuses
isert_device_get() for a device being removed and keeps a marker until
isert_exit(), measured with a CONNECT_REQUEST parked before the lookup.

Measured on soft-RoCE, three runs a side unless noted.  The nine cells v4
already passed report no KASAN, no lockdep splat and no refcount warning on
either side, login and I/O eighteen runs a side.  A REJ delivered to eight
promoted connections faulted the v4 removal walk every run and returned no
isert_device reference, where v5 finished it in fifteen seconds.  Over nine
runs a side the late-device window opened four times on v4, each of those
building one and taking ten or eleven core warnings, and twice on v5, which
built none.  1/5 alone took twenty-two use-after-frees to none, 2/5 alone
ten hung tasks to none, and PROVE_LOCKING gave no splat in twenty single
runs.

Yehyeong Lee (5):
  IB/isert: do not publish connections being released on a second list
  IB/isert: drain the QP without holding isert_conn->mutex
  IB/isert: tear connections down from an ib_client on device removal
  IB/isert: drop the promotion reference when a connection errors out
  IB/isert: do not build a new isert_device for a device being removed

 drivers/infiniband/ulp/isert/ib_isert.c | 420 ++++++++++++++++++------
 drivers/infiniband/ulp/isert/ib_isert.h |   9 +-
 2 files changed, 319 insertions(+), 110 deletions(-)


base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
-- 
2.43.0


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2026-11-03 22:39 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-03 12:59 [PATCH v5 0/5] IB/isert: fix the device removal use-after-free Yehyeong Lee
2026-11-03 12:59 ` [PATCH v5 1/5] IB/isert: do not publish connections being released on a second list Yehyeong Lee
2026-11-03 13:26   ` sashiko-bot
2026-11-03 12:59 ` [PATCH v5 2/5] IB/isert: drain the QP without holding isert_conn->mutex Yehyeong Lee
2026-11-03 13:21   ` sashiko-bot
2026-11-03 12:59 ` [PATCH v5 3/5] IB/isert: tear connections down from an ib_client on device removal Yehyeong Lee
2026-11-03 13:32   ` sashiko-bot
2026-11-03 12:59 ` [PATCH v5 4/5] IB/isert: drop the promotion reference when a connection errors out Yehyeong Lee
2026-11-03 13:16   ` sashiko-bot
2026-11-03 12:59 ` [PATCH v5 5/5] IB/isert: do not build a new isert_device for a device being removed Yehyeong Lee
2026-11-03 13:39   ` sashiko-bot
2026-11-03 22:39 ` [PATCH v5 0/5] IB/isert: fix the device removal use-after-free Yehyeong Lee

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.