* Re: CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe
2024-05-21 19:31 ` CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe Michal Hocko
@ 2024-05-22 4:10 ` Greg KH
2024-05-23 8:50 ` zhengzucheng
2024-05-24 10:33 ` Michal Hocko
2 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2024-05-22 4:10 UTC (permalink / raw)
To: Michal Hocko; +Cc: cve, linux-kernel, linux-cve-announce, Lee Jones
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe
2024-05-21 19:31 ` CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe Michal Hocko
2024-05-22 4:10 ` Greg KH
@ 2024-05-23 8:50 ` zhengzucheng
2024-05-23 13:51 ` Greg KH
2024-05-24 10:33 ` Michal Hocko
2 siblings, 1 reply; 6+ messages in thread
From: zhengzucheng @ 2024-05-23 8:50 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-cve-announce, Lee Jones, Jun.Ma2, cve, linux-kernel
在 2024/5/22 3:31, Michal Hocko 写道:
> 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.
hi Michal Hocko
This reverted patch was previously used to resolve CVE-2024-35928 ?
so CVE-2024-35928 should be rejected?
commit 03c6284df179de3a4a6e0684764b1c71d2a405e2
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Tue Mar 19 15:24:03 2024 +0800
Revert "drm/amd/amdgpu: Fix potential ioremap() memory leaks in
amdgpu_device_init()"
This patch causes the following iounmap erorr and calltrace
iounmap: bad address 00000000d0b3631f
The original patch was unjustified because amdgpu_device_fini_sw() will
always cleanup the rmmio mapping.
This reverts commit eb4f139888f636614dab3bcce97ff61cefc4b3a7.
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> On Tue 26-03-24 17:50:16, Lee Jones wrote:
>> Description
>> ===========
>>
>> In the Linux kernel, the following vulnerability has been resolved:
>>
>> platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe
>>
>> p2sb_bar() unhides P2SB device to get resources from the device. It
>> guards the operation by locking pci_rescan_remove_lock so that parallel
>> rescans do not find the P2SB device. However, this lock causes deadlock
>> when PCI bus rescan is triggered by /sys/bus/pci/rescan. The rescan
>> locks pci_rescan_remove_lock and probes PCI devices. When PCI devices
>> call p2sb_bar() during probe, it locks pci_rescan_remove_lock again.
>> Hence the deadlock.
>>
>> To avoid the deadlock, do not lock pci_rescan_remove_lock in p2sb_bar().
>> Instead, do the lock at fs_initcall. Introduce p2sb_cache_resources()
>> for fs_initcall which gets and caches the P2SB resources. At p2sb_bar(),
>> refer the cache and return to the caller.
>>
>> Before operating the device at P2SB DEVFN for resource cache, check
>> that its device class is PCI_CLASS_MEMORY_OTHER 0x0580 that PCH
>> specifications define. This avoids unexpected operation to other devices
>> at the same DEVFN.
>>
>> Tested-by Klara Modin <klarasmodin@gmail.com>
>>
>> The Linux kernel CVE team has assigned CVE-2024-26650 to this issue.
>>
>>
>> Affected and fixed versions
>> ===========================
>>
>> Issue introduced in 6.0 with commit 9745fb07474f and fixed in 6.1.76 with commit 2841631a0365
>> Issue introduced in 6.0 with commit 9745fb07474f and fixed in 6.6.15 with commit 847e1eb30e26
>> Issue introduced in 6.0 with commit 9745fb07474f and fixed in 6.7.3 with commit d281ac9a987c
>> Issue introduced in 6.0 with commit 9745fb07474f and fixed in 6.8 with commit 5913320eb0b3
>>
>> Please see https://www.kernel.org for a full list of currently supported
>> kernel versions by the kernel community.
>>
>> Unaffected versions might change over time as fixes are backported to
>> older supported kernel versions. The official CVE entry at
>> https://cve.org/CVERecord/?id=CVE-2024-26650
>> will be updated if fixes are backported, please check that for the most
>> up to date information about this issue.
>>
>>
>> Affected files
>> ==============
>>
>> The file(s) affected by this issue are:
>> drivers/platform/x86/p2sb.c
>>
>>
>> Mitigation
>> ==========
>>
>> The Linux kernel CVE team recommends that you update to the latest
>> stable kernel version for this, and many other bugfixes. Individual
>> changes are never tested alone, but rather are part of a larger kernel
>> release. Cherry-picking individual commits is not recommended or
>> supported by the Linux kernel community at all. If however, updating to
>> the latest release is impossible, the individual changes to resolve this
>> issue can be found at these commits:
>> https://git.kernel.org/stable/c/2841631a03652f32b595c563695d0461072e0de4
>> https://git.kernel.org/stable/c/847e1eb30e269a094da046c08273abe3f3361cf2
>> https://git.kernel.org/stable/c/d281ac9a987c553d93211b90fd4fe97d8eca32cd
>> https://git.kernel.org/stable/c/5913320eb0b3ec88158cfcb0fa5e996bf4ef681b
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe
2024-05-23 8:50 ` zhengzucheng
@ 2024-05-23 13:51 ` Greg KH
2024-05-24 10:33 ` Michal Hocko
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2024-05-23 13:51 UTC (permalink / raw)
To: zhengzucheng
Cc: Michal Hocko, linux-cve-announce, Lee Jones, Jun.Ma2, cve,
linux-kernel
On Thu, May 23, 2024 at 04:50:18PM +0800, zhengzucheng wrote:
>
> 在 2024/5/22 3:31, Michal Hocko 写道:
> > 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.
>
> hi Michal Hocko
>
> This reverted patch was previously used to resolve CVE-2024-35928 ?
>
> so CVE-2024-35928 should be rejected?
>
>
> commit 03c6284df179de3a4a6e0684764b1c71d2a405e2
> Author: Ma Jun <Jun.Ma2@amd.com>
> Date: Tue Mar 19 15:24:03 2024 +0800
>
> Revert "drm/amd/amdgpu: Fix potential ioremap() memory leaks in
> amdgpu_device_init()"
>
> This patch causes the following iounmap erorr and calltrace
> iounmap: bad address 00000000d0b3631f
>
> The original patch was unjustified because amdgpu_device_fini_sw() will
> always cleanup the rmmio mapping.
>
> This reverts commit eb4f139888f636614dab3bcce97ff61cefc4b3a7.
>
> Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
> Suggested-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yes, this should be rejected, I'll go do that now, thanks for pointing
out the revert, we missed that.
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe
2024-05-23 13:51 ` Greg KH
@ 2024-05-24 10:33 ` Michal Hocko
0 siblings, 0 replies; 6+ messages in thread
From: Michal Hocko @ 2024-05-24 10:33 UTC (permalink / raw)
To: Greg KH
Cc: zhengzucheng, linux-cve-announce, Lee Jones, Jun.Ma2, cve,
linux-kernel
On Thu 23-05-24 15:51:38, Greg KH wrote:
> On Thu, May 23, 2024 at 04:50:18PM +0800, zhengzucheng wrote:
> >
> > 在 2024/5/22 3:31, Michal Hocko 写道:
> > > 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.
> >
> > hi Michal Hocko
> >
> > This reverted patch was previously used to resolve CVE-2024-35928 ?
> >
> > so CVE-2024-35928 should be rejected?
> >
> >
> > commit 03c6284df179de3a4a6e0684764b1c71d2a405e2
> > Author: Ma Jun <Jun.Ma2@amd.com>
> > Date: Tue Mar 19 15:24:03 2024 +0800
> >
> > Revert "drm/amd/amdgpu: Fix potential ioremap() memory leaks in
> > amdgpu_device_init()"
> >
> > This patch causes the following iounmap erorr and calltrace
> > iounmap: bad address 00000000d0b3631f
> >
> > The original patch was unjustified because amdgpu_device_fini_sw() will
> > always cleanup the rmmio mapping.
> >
> > This reverts commit eb4f139888f636614dab3bcce97ff61cefc4b3a7.
> >
> > Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
> > Suggested-by: Christian König <christian.koenig@amd.com>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>
> Yes, this should be rejected, I'll go do that now, thanks for pointing
> out the revert, we missed that.
yes, I meant this one indeed! Sorry about the confusion.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe
2024-05-21 19:31 ` CVE-2024-26650: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe Michal Hocko
2024-05-22 4:10 ` Greg KH
2024-05-23 8:50 ` zhengzucheng
@ 2024-05-24 10:33 ` Michal Hocko
2 siblings, 0 replies; 6+ messages in thread
From: Michal Hocko @ 2024-05-24 10:33 UTC (permalink / raw)
To: cve, linux-kernel; +Cc: linux-cve-announce, Lee Jones
On Tue 21-05-24 21:31:54, 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.
Wait a second. I've screwed up here. I am sorry, my bad. This revert has
nothing to do with CVE-2024-26650 - 5913320eb0b3 ("platform/x86: p2sb:
Allow p2sb_bar() calls during PCI device probe"). I guess I got
completely confused by the fact that the same change exists under a
different commit b28ff7a7c324 ("platform/x86: p2sb: Allow p2sb_bar()
calls during PCI device probe").
I must have mixed this with CVE-2024-35928 somehow. zhengzucheng has
already pointed to that one. Sorry about that!
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 6+ messages in thread