From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-64033: RDMA/rtrs: Fix use-after-free in path file creation cleanup
Date: Sun, 19 Jul 2026 17:38:15 +0200 [thread overview]
Message-ID: <2026071904-CVE-2026-64033-b08e@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs: Fix use-after-free in path file creation cleanup
In the error path of rtrs_srv_create_path_files(), the sysfs root folders
may already have been created and srv_path->kobj may already have been
initialized. If a later step fails, the cleanup currently calls
kobject_put(&srv_path->kobj) before
rtrs_srv_destroy_once_sysfs_root_folders(srv_path).
kobject_put() may drop the last reference to srv_path->kobj and invoke the
release callback, rtrs_srv_release(), which frees srv_path. The following
call to rtrs_srv_destroy_once_sysfs_root_folders(srv_path) then
dereferences srv_path internally to access srv_path->srv, resulting in a
use-after-free.
This failure path is reached before rtrs_srv_create_path_files() returns
success, so the successful-path lifetime handling is not involved.
Fix this by destroying the sysfs root folders before calling
kobject_put(&srv_path->kobj), so srv_path is still valid while the helper
accesses it.
This issue was found by a static analysis tool I am developing.
The Linux kernel CVE team has assigned CVE-2026-64033 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.15.61 with commit bab17b761c8974a869b04462be5d4dd9aad366b4 and fixed in 5.15.209 with commit 01e42aabaf7632beb4bf235c7238b96c746d4144
Issue introduced in 5.17 with commit ae4c81644e9105d9f7f713bb0d444737bb6a0cf1 and fixed in 6.1.175 with commit 548f3956e53a7f7bde912d8129010b8986d5e602
Issue introduced in 5.17 with commit ae4c81644e9105d9f7f713bb0d444737bb6a0cf1 and fixed in 6.6.142 with commit 00904a73272b9f3ef3952fe69a833909dccad1ef
Issue introduced in 5.17 with commit ae4c81644e9105d9f7f713bb0d444737bb6a0cf1 and fixed in 6.12.92 with commit 92060ab1c5115674cf319175550f85f68405121f
Issue introduced in 5.17 with commit ae4c81644e9105d9f7f713bb0d444737bb6a0cf1 and fixed in 6.18.34 with commit eae62c5451e67e8b033c1681fd3b85d7e9a9a28f
Issue introduced in 5.17 with commit ae4c81644e9105d9f7f713bb0d444737bb6a0cf1 and fixed in 7.0.11 with commit b0e9706fb2859064bb6c677554c4d20c713aa8e0
Issue introduced in 5.17 with commit ae4c81644e9105d9f7f713bb0d444737bb6a0cf1 and fixed in 7.1 with commit 5b74373390113fba798a76b483837029ab010fef
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-64033
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/01e42aabaf7632beb4bf235c7238b96c746d4144
https://git.kernel.org/stable/c/548f3956e53a7f7bde912d8129010b8986d5e602
https://git.kernel.org/stable/c/00904a73272b9f3ef3952fe69a833909dccad1ef
https://git.kernel.org/stable/c/92060ab1c5115674cf319175550f85f68405121f
https://git.kernel.org/stable/c/eae62c5451e67e8b033c1681fd3b85d7e9a9a28f
https://git.kernel.org/stable/c/b0e9706fb2859064bb6c677554c4d20c713aa8e0
https://git.kernel.org/stable/c/5b74373390113fba798a76b483837029ab010fef
reply other threads:[~2026-07-19 15:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=2026071904-CVE-2026-64033-b08e@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@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