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: <2025071002-festive-outcast-7edd@gregkh>
Date: Thu, 10 Jul 2025 15:41:53 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Xinyu Zheng <zhengxinyu6@...wei.com>
Cc: mst@...hat.com, jasowang@...hat.com, pbonzini@...hat.com,
	stefanha@...hat.com, virtualization@...ts.linux-foundation.org,
	kvm@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v5.10] vhost-scsi: protect vq->log_used with vq->mutex

On Wed, Jul 02, 2025 at 08:29:45AM +0000, Xinyu Zheng wrote:
> From: Dongli Zhang <dongli.zhang@...cle.com>
> 
> [ Upstream commit f591cf9fce724e5075cc67488c43c6e39e8cbe27 ]
> 
> The vhost-scsi completion path may access vq->log_base when vq->log_used is
> already set to false.
> 
>     vhost-thread                       QEMU-thread
> 
> vhost_scsi_complete_cmd_work()
> -> vhost_add_used()
>    -> vhost_add_used_n()
>       if (unlikely(vq->log_used))
>                                       QEMU disables vq->log_used
>                                       via VHOST_SET_VRING_ADDR.
>                                       mutex_lock(&vq->mutex);
>                                       vq->log_used = false now!
>                                       mutex_unlock(&vq->mutex);
> 
> 				      QEMU gfree(vq->log_base)
>         log_used()
>         -> log_write(vq->log_base)
> 
> Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be
> reclaimed via gfree(). As a result, this causes invalid memory writes to
> QEMU userspace.
> 
> The control queue path has the same issue.
> 
> CVE-2025-38074

This is not needed.

> Cc: stable@...r.kernel.org#5.10.x

What about 5.15.y and 6.1.y?  We can't take a patch just for 5.10 as
that would cause regressions, right?

Please provide all relevant backports and I will be glad to queue them
up then.  I'll drop this from my queue for now, thanks.

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ