In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()
In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update
inbound map address") set_bar() was modified to support dynamically
changing the backing physical address of a BAR that was already configured.
This means that set_bar() can be called twice, without ever calling
clear_bar() (as calling clear_bar() would clear the BAR's PCI address
assigned by the host).
This can only be done if the new BAR size/flags does not differ from the
existing BAR configuration. Add these missing checks.
If we allow set_bar() to set e.g. a new BAR size that differs from the
existing BAR size, the new address translation range will be smaller than
the BAR size already determined by the host, which would mean that a read
past the new BAR size would pass the iATU untranslated, which could allow
the host to read memory not belonging to the new struct pci_epf_bar.
While at it, add comments which clarifies the support for dynamically
changing the physical address of a BAR. (Which was also missing.)
PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()
In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update
inbound map address") set_bar() was modified to support dynamically
changing the backing physical address of a BAR that was already configured.
This means that set_bar() can be called twice, without ever calling
clear_bar() (as calling clear_bar() would clear the BAR's PCI address
assigned by the host).
This can only be done if the new BAR size/flags does not differ from the
existing BAR configuration. Add these missing checks.
If we allow set_bar() to set e.g. a new BAR size that differs from the
existing BAR size, the new address translation range will be smaller than
the BAR size already determined by the host, which would mean that a read
past the new BAR size would pass the iATU untranslated, which could allow
the host to read memory not belonging to the new struct pci_epf_bar.
While at it, add comments which clarifies the support for dynamically
changing the physical address of a BAR. (Which was also missing.)
Metrics
Affected Vendors & Products
Advisories
Source | ID | Title |
---|---|---|
![]() |
EUVD-2025-5196 | In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar() In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured. This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host). This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks. If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar. While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.) |
![]() |
USN-7521-1 | Linux kernel vulnerabilities |
![]() |
USN-7521-2 | Linux kernel (AWS) vulnerabilities |
![]() |
USN-7521-3 | Linux kernel vulnerabilities |
![]() |
USN-7651-1 | Linux kernel vulnerabilities |
![]() |
USN-7651-2 | Linux kernel vulnerabilities |
![]() |
USN-7651-3 | Linux kernel vulnerabilities |
![]() |
USN-7651-4 | Linux kernel (GCP) vulnerabilities |
![]() |
USN-7651-5 | Linux kernel (Raspberry Pi Real-time) vulnerabilities |
![]() |
USN-7651-6 | Linux kernel (Raspberry Pi) vulnerabilities |
![]() |
USN-7652-1 | Linux kernel (Real-time) vulnerabilities |
![]() |
USN-7653-1 | Linux kernel (HWE) vulnerabilities |
![]() |
USN-7737-1 | Linux kernel (Azure) vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Thu, 23 Oct 2025 13:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Weaknesses | NVD-CWE-noinfo | |
CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
Fri, 28 Feb 2025 02:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Thu, 27 Feb 2025 02:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar() In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured. This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host). This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks. If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar. While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.) | |
Title | PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar() | |
References |
|

Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-05-04T10:08:15.420Z
Reserved: 2025-02-27T02:10:48.227Z
Link: CVE-2024-58006

No data.

Status : Analyzed
Published: 2025-02-27T03:15:11.583
Modified: 2025-10-23T13:04:07.040
Link: CVE-2024-58006


Updated: 2025-07-12T22:01:14Z