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>] [day] [month] [year] [list]
Message-ID: <2024052216-detest-whiff-15e3@gregkh>
Date: Wed, 22 May 2024 06:10:09 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Michal Hocko <mhocko@...e.com>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org, Lee Jones <lee@...nel.org>
Subject: Re: CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls
 during PCI device probe

On Tue, May 21, 2024 at 09:31:54PM +0200, Michal Hocko wrote:
> This patch has been reverted in upstream by 03c6284df179 ("Revert
> "drm/amd/amdgpu: Fix potential ioremap() memory leaks in
> amdgpu_device_init()"") and based on the changelog the CVE should be
> rejected.

Ok, the original commit here happened in these releases:
	6.1.76 6.6.15 6.7.3 6.8
while the revert is only in these releases:
	6.1.86 6.6.27 6.8.6 6.9
but there are also commits in these releases that reference the original
commit and also say they fix it:
	6.1.84 6.6.23 6.7.11
i.e. commit aec7d25b497c ("platform/x86: p2sb: On Goldmont only cache
P2SB and SPI devfn BAR") so that commit is also needed in order to make
this commit work properly, in other words, the original isn't totally
invalid on it's own.

So the revert is a fix for the original patch, and needs to keep being a
CVE, but you think that the original should not be because it was
reverted, right?

That kind of makes sense, but at the time, the original was a valid CVE,
so we were correct to assign that, what do we do about the "middle" one
here, ignore it?  Without both of them, you might have a problem still
but I guess that's up to the systems that cherry-pick to work out,
right?

Should we be searching the database for assigned CVEs to the commits
that new ones are marked as "Fixes:" for and think about how to revoke
those original ones at the same time?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ