Re: CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe

[Greg KH <gregkh@linuxfoundation.org>]

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