linux-kernel - Re: CVE-2024-26650: platform/x86: p2sb: Allow p2sb

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: <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