data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2024-58006 in the interactive tracker

CVE-2024-58006

PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()

9.6 EPSS 0.2% AV:A

Published 2025-02-27 (20 months ago) by the Linux kernel CNA. Subsystem drivers/pci. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2024-58006 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

ReleaseStatus VersionWhat this means
Debian 12bookwormvulnerable6.1.190-1No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixiefixed6.12.15-1Update the kernel and reboot. Fixed in 6.12.15-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed6.12.15-1Update the kernel and reboot. Fixed in 6.12.15-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed6.12.15-1Update the kernel and reboot. Fixed in 6.12.15-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

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.)

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/pci/controller/dwc/pcie-designware-ep.c

What this is
PCI DRIVER FOR SYNOPSYS DESIGNWAREMAINTAINERS section matched on drivers/pci/controller/dwc/*designware* · linux-pci@vger.kernel.org · Maintained

Check it on the machine

grep -w CONFIG_PCIE_DW_EP /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian does not build this code in 1 release. It does build it in 3 releases, so the answer depends on which release the machine runs.

  • bookwormn
  • trixieYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
  • forky, sidYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
n
not enabled on any flavour - this release does not build the code
Y
built in where it is built at all; some flavours do not build it
Build switch
CONFIG_PCIE_DW_EP

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published
2025-02-27 (20 months ago)source
CVSS
9.6 critical
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it
Attack vector
adjacent network (AV:A)source
EPSS
0.24%, higher than 13.4% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
not yet assignedsource
Subsystem
drivers/pci

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
6.06.12.14b5cacfd06706
6.06.13.33229c15d6267
6.06.143708acbd5f16

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:AAttack vector, adjacent network
The attacker is the PCIe root complex on the other end of an existing point-to-point link (the classic Linux EP deployment: DPU/SmartNIC/accelerator or NTB host-to-host interconnect), sending TLPs and scratchpad writes over a shared, non-routable fabric — a logically adjacent topology. No physical manipulation of the endpoint is needed at exploit time, so this is Adjacent rather than Physical or Local.
AC:LAttack complexity, low
The peer host fully and deterministically controls the memory-window size it advertises in the NTB scratchpads, which propagates unvalidated to `epf_bar->size` and reprograms the inbound iATU; there is no race, timing window, or memory-layout condition outside the attacker's control.
PR:NPrivileges required, none
NTB link negotiation performs no authentication whatsoever — the endpoint reads the size scratchpads from the host-writable control BAR as soon as the link comes up, so the attacking host needs no credentials or privileges on the endpoint system.
UI:NUser interaction, none
The endpoint's `ntb_transport_link_work()` runs automatically on link-up and consumes the host-supplied sizes with no operator action; the attacker drives the entire sequence from its own side of the link.
S:CScope, changed
The inbound iATU is the endpoint's address-translation and containment boundary for host-originated transactions — the endpoint-side equivalent of an IOMMU — and this bug lets transactions pass it untranslated. A failure of that DMA/address-translation boundary lets one security authority (the remote host) reach memory in a different authority (the endpoint OS), matching the IOMMU/DMA-bypass Changed criterion.
C:HConfidentiality impact, high
With the BAR aperture larger than the translation window, the host can read endpoint physical memory outside the backing `pci_epf_bar` allocation — the commit message states this explicitly — yielding a large out-of-bounds/effectively arbitrary kernel memory read.
I:HIntegrity impact, high
PCI memory BAR windows are read/write, so the same mis-sized window gives the host out-of-bounds writes into endpoint physical memory beyond the intended buffer, corrupting adjacent kernel data or code and enabling control-flow hijacking on the endpoint.
A:HAvailability impact, high
Arbitrary writes into endpoint physical memory readily panic the kernel, and untranslated transactions escaping the iATU onto the internal bus can raise bus errors/aborts, crashing or hanging the endpoint system.