mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Hillf Danton <hdanton@sina.com>
Cc: Mike Christie <michael.christie@oracle.com>,
	"lizhijian@fujitsu.com" <lizhijian@fujitsu.com>,
	Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"target-devel@vger.kernel.org" <target-devel@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: use-after-free in srpt_enable_tpg()
Date: Mon, 4 Jul 2022 21:34:07 -0700	[thread overview]
Message-ID: <a671867f-153c-75a4-0f58-8dcb0d4f9c19@acm.org> (raw)
In-Reply-To: <20220704001157.1644-1-hdanton@sina.com>

On 7/3/22 17:11, Hillf Danton wrote:
> On Sun, 3 Jul 2022 07:55:05 -0700 Bart Van Assche wrote:
>> However, I'm not sure that would make a
>> significant difference since there is a similar while-loop in one of the
>> callers of srpt_remove_one() (disable_device() in the RDMA core).
> 
> Hehe... feel free to shed light on how the loop in RDMA core is currently
> making the loop in srpt more prone to uaf?

In my email I was referring to the following code in disable_device():

        wait_for_completion(&device->unreg_completion);

I think that code shows that device removal by the RDMA core is 
synchronous in nature. Even if the ib_srpt source code would be modified 
such that the objects referred by that code live longer, the wait loop 
in disable_device() would wait for the ib_device reference counts to 
drop to zero.

So I do not expect that modifying object lifetimes in ib_srpt.c can lead 
to a solution.

Removing configfs directories from inside srpt_release_sport() could be 
a solution. However, configfs does not have any API to remove 
directories and I'm not aware of any plans to add such an API. 
Additionally, several kernel maintainers disagree with invoking the 
rmdir system call from inside kernel code.

A potential solution could be to decouple the lifetimes of the data 
structures used for configfs (struct se_wwn and struct srpt_tpg) and the 
data structures associated with RDMA objects (struct srpt_port). If 
nobody else beats me to this I will try to find the time to implement 
this approach.

Bart.

  parent reply	other threads:[~2022-07-05  4:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27  7:09 lizhijian
2022-06-27 16:37 ` Bart Van Assche
2022-06-30 16:40   ` Mike Christie
2022-06-30 18:42     ` Bart Van Assche
     [not found]     ` <20220701015934.1105-1-hdanton@sina.com>
2022-07-02 22:26       ` Bart Van Assche
     [not found]       ` <20220703021119.1109-1-hdanton@sina.com>
2022-07-03 14:55         ` Bart Van Assche
     [not found]         ` <20220704001157.1644-1-hdanton@sina.com>
2022-07-05  4:34           ` Bart Van Assche [this message]
2022-07-05 12:39             ` Jason Gunthorpe
2022-07-27  3:24             ` lizhijian
     [not found]           ` <20220705114050.1979-1-hdanton@sina.com>
2022-07-05 16:10             ` Bart Van Assche

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=a671867f-153c-75a4-0f58-8dcb0d4f9c19@acm.org \
    --to=bvanassche@acm.org \
    --cc=hdanton@sina.com \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lizhijian@fujitsu.com \
    --cc=michael.christie@oracle.com \
    --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

all inboxes | Powered by JetHome®