mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yuqiang Sun <izaiahsun@gmail.com>
To: haris.iqbal@ionos.com, jinpu.wang@ionos.com
Cc: jgg@ziepe.ca, leon@kernel.org, guoqing.jiang@linux.dev,
	gi-oh.kim@ionos.com, aleksei.marov@ionos.com,
	lgs201920130244@gmail.com, linux-rdma@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/3] RDMA/rtrs-srv: fix use-after-free on sysfs setup failure
Date: Thu, 29 Oct 2026 12:27:16 +0800	[thread overview]
Message-ID: <20261029042719.75868-1-izaiahsun@gmail.com> (raw)

These patches fix use-after-free bugs on the error paths of the rtrs
server's sysfs setup, reached when a client's info request arrives and
creating the sysfs entries for its path fails.

Patch 1 is about what remains after commit 5b7437339011 ("RDMA/rtrs:
Fix use-after-free in path file creation cleanup", CVE-2026-64033).
That commit reordered the cleanup inside rtrs_srv_create_path_files(),
but the final kobject_put() there still frees srv_path while the caller
keeps using it and frees it again later; the stats kobject has the same
problem.

Patch 2 balances the session device reference: on these failure paths
it is dropped without having been taken, which frees the whole server
session while it is still in use.  Besides allocation failures,
device_add() also fails when a client sends an empty pathname, which
patch 3 rejects.

I first sent this to security@kernel.org, since the empty pathname
makes patch 2's bug reachable from the network.  The conclusion there
was that rtrs is deployed on trusted storage networks only, so this is
an ordinary bug and the series should simply be posted here.  Thanks to
everyone who replied so quickly.

The bugs were found on v7.2.12 and are present in the rdma for-next
branch, which this series is based on.  They were reproduced with KASAN
under KVM (soft-RoCE, rnbd mapping a brd device) by failing one
allocation at a time with failslab, restricted by call stack to the
sysfs setup, and the fixes were tested the same way, with lockdep and
kmemleak, and also with CONFIG_DEBUG_KOBJECT_RELEASE.  The empty
pathname was tested with a small user-space rtrs client.  The
reproduction setup is available on request.  Failures of the two
sysfs_create_group() calls were not injected, and nothing was tested on
RDMA hardware.

Two things seen while testing are not addressed here:

- The same pattern (a sysfs helper putting a kobject whose release
  frees an object its caller still owns) is present in the rtrs client
  (rtrs_clt_create_path_files() and both its callers) and in the rnbd
  server; separate reports and patches will follow.
- With CONFIG_DEBUG_KOBJECT_RELEASE, a normal map, I/O and unmap
  without fault injection triggers KASAN use-after-free reports from
  rnbd_destroy_sess_dev(), run as a delayed kobject release after the
  session it uses was freed by rnbd_srv_link_ev(); this happens with
  and without this series and will be reported with the rnbd issues.

The bugs were found with kbound, a research static analysis prototype,
and the patches were prepared with the help of an AI assistant, as
noted in the Assisted-by tags; I have reviewed and tested them as
described.

Yuqiang Sun (3):
  RDMA/rtrs-srv: Do not free the path on path file creation failure
  RDMA/rtrs-srv: Balance the session device reference in sysfs setup
  RDMA/rtrs-srv: Reject an empty pathname

 drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 37 +++++++++++---------
 drivers/infiniband/ulp/rtrs/rtrs-srv.c       | 19 ++++++++--
 2 files changed, 38 insertions(+), 18 deletions(-)


base-commit: c3e8e9451e6f1b69f685b75e0fbf14f3d0fb2539
-- 
2.53.0

             reply	other threads:[~2026-10-29  4:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29  4:27 Yuqiang Sun [this message]
2026-10-29  4:27 ` [PATCH 1/3] RDMA/rtrs-srv: Do not free the path on path file creation failure Yuqiang Sun
2026-10-29  4:27 ` [PATCH 2/3] RDMA/rtrs-srv: Balance the session device reference in sysfs setup Yuqiang Sun
2026-10-29  4:27 ` [PATCH 3/3] RDMA/rtrs-srv: Reject an empty pathname Yuqiang Sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261029042719.75868-1-izaiahsun@gmail.com \
    --to=izaiahsun@gmail.com \
    --cc=aleksei.marov@ionos.com \
    --cc=gi-oh.kim@ionos.com \
    --cc=guoqing.jiang@linux.dev \
    --cc=haris.iqbal@ionos.com \
    --cc=jgg@ziepe.ca \
    --cc=jinpu.wang@ionos.com \
    --cc=leon@kernel.org \
    --cc=lgs201920130244@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®