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)?
--
Michal Hocko
SUSE Labs
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.
--
Lee Jones [李琼斯]
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?
--
Michal Hocko
SUSE Labs
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.
--
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/[email protected]/
Thank you for your input Michal.
--
Lee Jones [李琼斯]
On Wed 20-03-24 16:51:27, Lee Jones wrote:
> 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.
yes I do agree that WARN() should be treated same as BUG() if
triggerable by an user (for reasons you have mentioned). Lockdep is a
different thing as you follow up below.
> 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/[email protected]/
>
> Thank you for your input Michal.
Thanks!
--
Michal Hocko
SUSE Labs