{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-58006",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-58006"
  ],
  "published": "2025-02-27T02:12:01Z",
  "summary": "PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()\n\nIn commit 4284c88fff0e (\"PCI: designware-ep: Allow pci_epc_set_bar() update\ninbound map address\") set_bar() was modified to support dynamically\nchanging the backing physical address of a BAR that was already configured.\n\nThis means that set_bar() can be called twice, without ever calling\nclear_bar() (as calling clear_bar() would clear the BAR's PCI address\nassigned by the host).\n\nThis can only be done if the new BAR size/flags does not differ from the\nexisting BAR configuration. Add these missing checks.\n\nIf we allow set_bar() to set e.g. a new BAR size that differs from the\nexisting BAR size, the new address translation range will be smaller than\nthe BAR size already determined by the host, which would mean that a read\npast the new BAR size would pass the iATU untranslated, which could allow\nthe host to read memory not belonging to the new struct pci_epf_bar.\n\nWhile at it, add comments which clarifies the support for dynamically\nchanging the physical address of a BAR. (Which was also missing.)",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": null,
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-58006"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/b5cacfd067060c75088363ed3e19779078be2755"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3229c15d6267de8e704b4085df8a82a5af2d63eb"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3708acbd5f169ebafe1faa519cb28adc56295546"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:52:36Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 9.6,
      "cvss_v3_severity": "Critical",
      "scenario": "AV:A - 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 \u2014 a logically adjacent topology. No physical manipulation of the endpoint is needed at exploit time, so this is Adjacent rather than Physical or Local.\nAC:L - 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.\nPR:N - NTB link negotiation performs no authentication whatsoever \u2014 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.\nUI:N - 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.\nS:C - The inbound iATU is the endpoint's address-translation and containment boundary for host-originated transactions \u2014 the endpoint-side equivalent of an IOMMU \u2014 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.\nC:H - With the BAR aperture larger than the translation window, the host can read endpoint physical memory outside the backing `pci_epf_bar` allocation \u2014 the commit message states this explicitly \u2014 yielding a large out-of-bounds/effectively arbitrary kernel memory read.\nI:H - 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.\nA:H - 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."
    }
  }
}