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
next 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®