linux-kernel - Re: [PATCH v3] vfio: fix potential deadlock on vfio group lock

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y8G8eNhmjc1QK4tC@nvidia.com>
Date:   Fri, 13 Jan 2023 16:18:00 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Matthew Rosato <mjrosato@...ux.ibm.com>
Cc:     alex.williamson@...hat.com, pbonzini@...hat.com, cohuck@...hat.com,
        farman@...ux.ibm.com, pmorel@...ux.ibm.com,
        borntraeger@...ux.ibm.com, frankja@...ux.ibm.com,
        imbrenda@...ux.ibm.com, david@...hat.com, akrowiak@...ux.ibm.com,
        jjherne@...ux.ibm.com, pasic@...ux.ibm.com,
        zhenyuw@...ux.intel.com, zhi.a.wang@...el.com, seanjc@...gle.com,
        linux-s390@...r.kernel.org, kvm@...r.kernel.org,
        intel-gvt-dev@...ts.freedesktop.org,
        intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] vfio: fix potential deadlock on vfio group lock

On Fri, Jan 13, 2023 at 03:09:01PM -0500, Matthew Rosato wrote:

> > This still doesn't seem right, another thread could have incr'd the
> > open_count already 
> > 
> > This has to be done at the moment open_count is decremented to zero,
> > while still under the original lock.
> 
> Hmm..  Fair.  Well, we can go back to clearing of device->kvm in
> vfio_device_last_close but the group lock is held then so we can't
> immediately do the kvm_put at that time -- unless we go back to the
> notion of stacking the kvm_put on a workqueue, but now from vfio.
> If we do that, I think we also have to scrap the idea of putting the
> kvm_put_kvm function pointer into device->put_kvm too (or otherwise
> stash it along with the kvm value to be picked up by the scheduled
> work).

Well, you have to keep the same sort of design, the
vfio_device_last_close() has to put the kvm on the stack until the
group lock is unlocked.

It is messy due to how the functions are nested, but not hard.

Jason