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: <ZuXgzRSPx7hN6ASO@vaman>
Date: Sun, 15 Sep 2024 00:45:25 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
	yung-chuan.liao@...ux.intel.com,
	pierre-louis.bossart@...ux.intel.com,
	krzysztof.kozlowski@...aro.org, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH stable-6.10 regression] Revert "soundwire: stream: fix
 programming slave ports for non-continous port maps"

On 13-09-24, 17:21, Vinod Koul wrote:
> On 11-09-24, 14:31, Greg KH wrote:
> > On Tue, Sep 10, 2024 at 04:02:29PM +0300, Péter Ujfalusi wrote:
> > > Hi,
> > > 
> > > On 10/09/2024 15:40, Peter Ujfalusi wrote:
> > > > The prop->src_dpn_prop and prop.sink_dpn_prop is allocated for the _number_
> > > > of ports and it is forced as 0 index based.
> > > > 
> > > > The original code was correct while the change to walk the bits and use
> > > > their position as index into the arrays is not correct.
> > > > 
> > > > For exmple we can have the prop.source_ports=0x2, which means we have one
> > > > port, but the prop.src_dpn_prop[1] is accessing outside of the allocated
> > > > memory.
> > > > 
> > > > This reverts commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3.
> > > 
> > > I just noticed that Krzysztof already sent the revert patch but it is
> > > not picked up for stable-6.10.y
> > > 
> > > https://lore.kernel.org/lkml/20240909164746.136629-1-krzysztof.kozlowski@linaro.org/
> > 
> > Is this in Linus's tree yet?  That's what we are waiting for.
> 
> Yes I was waiting for that as well, the pull request has been sent to
> Linus, this should be in his tree, hopefully tomorow..

It is in Linus's tree now. Greg would you like to drop commit
6fa78e9c41471fe43052cd6feba6eae1b0277ae3 or carry it and the
revert...?

What is the usual process for you to handle reverts?
-- 
~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ