Target-devel archive mirror
 help / color / mirror / Atom feed
From: William Kucharski <william.kucharski@oracle.com>
To: Bart Van Assche <bvanassche@acm.org>,
	Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
	linux-rdma@vger.kernel.org, target-devel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: William Kucharski <william.kucharski@oracle.com>
Subject: [PATCH v2 0/1] RDMA/srpt: Do not register event handler until srpt device is fully setup
Date: Fri,  2 Feb 2024 02:15:48 -0700	[thread overview]
Message-ID: <20240202091549.991784-1-william.kucharski@oracle.com> (raw)

Upon occasion, KASAN testing would report a use-after-free Write in
srpt_refresh_port().

In the course of trying to diagnose this, I noticed that the code in
srpt_add_one() registers an event handler for the srpt device and then
initializes the ports on the device. If any portion of the
device port initialization fails, it removes the registration for the
event handler in the error leg.

This felt like a race condition, where an event handler was registered
before the device ports were fully initialized.

While I can't definitively say this was the issue - this change may just
modify timing to mask the real issue - when modified to not register
the event handler until all of the device ports are intialized,
the issue no longer reproduces in KASAN.

Changelog:
v2:
  * Added Fixes tag

William Kucharski (1):
  RDMA/srpt: Do not register event handler until srpt device is fully setup

 drivers/infiniband/ulp/srpt/ib_srpt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.39.3


Upon occasion, KASAN testing would report a use-after-free Write in
srpt_refresh_port().

In the course of trying to diagnose this, I noticed that the code in
srpt_add_one() registers an event handler for the srpt device and then
initializes the ports on the device. If any portion of the
device port initialization fails, it removes the registration for the
event handler in the error leg.

This felt like a race condition, where an event handler was registered
before the device ports were fully initialized.

While I can't definitively say this was the issue - this change may just
modify timing to mask the real issue - when modified to not register
the event handler until all of the device ports are intialized,
the issue no longer reproduces in KASAN.

I'm submitting  this patch if only so those better acquainted with
the details of this procedure can analyze whether this was an actual
issue or just intellectual uncomfortableness with the code.

William Kucharski (1):
  Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port().

 drivers/infiniband/ulp/srpt/ib_srpt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.43.0


             reply	other threads:[~2024-02-02  9:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02  9:15 William Kucharski [this message]
2024-02-02  9:15 ` [PATCH v2 1/1] RDMA/srpt: Do not register event handler until srpt device is fully setup William Kucharski
2024-02-04  9:46   ` Leon Romanovsky
2024-02-04  9:46 ` [PATCH v2 0/1] " Leon Romanovsky

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=20240202091549.991784-1-william.kucharski@oracle.com \
    --to=william.kucharski@oracle.com \
    --cc=bvanassche@acm.org \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=target-devel@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).