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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240320165127.GV1522089@google.com>
Date: Wed, 20 Mar 2024 16:51:27 +0000
From: Lee Jones <lee@...nel.org>
To: Michal Hocko <mhocko@...e.com>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Felix Kuehling <felix.kuehling@....com>
Subject: Re: CVE-2024-26628: drm/amdkfd: Fix lock dependency warning

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@kernel.org/

Thank you for your input Michal.

-- 
Lee Jones [李琼斯]