lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 27 Jun 2022 06:47:36 +0000
From:   "lizhijian@...itsu.com" <lizhijian@...itsu.com>
To:     Jason Gunthorpe <jgg@...dia.com>,
        Bart Van Assche <bvanassche@....org>
CC:     Leon Romanovsky <leon@...nel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] RDMA/srp: Fix use-after-free in srp_exit_cmd_priv



Sorry for the late reply

On 25/06/2022 07:47, Jason Gunthorpe wrote:
> On Fri, Jun 24, 2022 at 04:26:06PM -0700, Bart Van Assche wrote:
>> On 6/24/22 15:59, Jason Gunthorpe wrote:
>>> I don't even understand how get_device() prevents this call chain??
>>>
>>> It looks to me like the problem is srp_remove_one() is not waiting for
>>> or canceling some outstanding work.
>> Hi Jason,
>>
>> My conclusions from the call traces in Li's email are as follows:
>> * scsi_host_dev_release() can get called after srp_remove_one().
>> * srp_exit_cmd_priv() uses the ib_device pointer. If srp_remove_one() is
>> called before srp_exit_cmd_priv() then a use-after-free is triggered.
> Shouldn't srp_remove_one() wait for the scsi_host_dev to complete
> destruction? Clearly it cannot continue to exist once the IB device
> has been removed
Yes, that match my first thought, but i didn't know the exact way to notify scsi side to destroy
itself but scsi_host_put() which already called once in below chains:

srp_remove_one()
  -> srp_queue_remove_work()
     -> srp_remove_target()
        -> scsi_remove_host()
        -> scsi_host_put()

that means scsi_host_dev is still referenced by other components that we have to notify.


>
>> Is calling get_device() and put_device() on the struct ib_device an
>> acceptable way to fix this?
> As I said, I don't understand at all how this works. get_device() does
> not prevent srp_remove_one() from being called.
I originally thought that srp_remove_one was called from put_device(ibdev) ,  so increase its ref_count can avoid it being released early.


Thanks
Zhijian



> Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ