Re: CVE-2024-26628: drm/amdkfd: Fix lock dependency warning

[Lee Jones]

On Wed, 20 Mar 2024, Lee Jones wrote:

> On Wed, 20 Mar 2024, Michal Hocko wrote:
> 
> > On Thu 14-03-24 11:09:38, Lee Jones wrote:
> > > On Fri, 08 Mar 2024, Michal Hocko wrote:
> > > 
> > > > On Wed 06-03-24 06:46:11, Greg KH wrote:
> > > > [...]
> > > > >  Possible unsafe locking scenario:
> > > > > 
> > > > >        CPU0                    CPU1
> > > > >        ----                    ----
> > > > >   lock(&svms->lock);
> > > > >                                lock(&mm->mmap_lock);
> > > > >                                lock(&svms->lock);
> > > > >   lock((work_completion)(&svm_bo->eviction_work));
> > > > > 
> > > > > I believe this cannot really lead to a deadlock in practice, because
> > > > > svm_range_evict_svm_bo_worker only takes the mmap_read_lock if the BO
> > > > > refcount is non-0. That means it's impossible that svm_range_bo_release
> > > > > is running concurrently. However, there is no good way to annotate this.
> > > > 
> > > > OK, so is this even a bug (not to mention a security/weakness)?
> > > 
> > > Looks like the patch fixes a warning which can crash some kernels.  So
> > > the CVE appears to be fixing that, rather than the impossible deadlock.
> > 
> > Are you talking about lockdep warning or anything else?
> 
> Anything that triggers a BUG() or a WARN() (as per the splat in the
> commit message).  Many in-field kernels are configured to panic on
> BUG()s and WARN()s, thus triggering them are presently considered local
> DoS and attract CVE status.

We have discussed this internally and agree with your thinking.

The splat in the circular lockdep detection code appears to be generated
using some stacked pr_warn() calls, rather than a WARN().

Thus, CVE-2024-26628 has now been rejected.

  https://lore.kernel.org/all/20240320164818.3778843-2-lee@xxxxxxxxxx/

Thank you for your input Michal.

-- 
Lee Jones [李琼斯]