{"vulnerability": "CVE-2024-58006", "sightings": [{"uuid": "2d823197-fa22-43a8-af17-b9efa3b556f4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-58006", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/14764", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-58006\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: 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.)\n\ud83d\udccf Published: 2025-02-27T02:12:02.932Z\n\ud83d\udccf Modified: 2025-05-04T10:08:15.420Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/b5cacfd067060c75088363ed3e19779078be2755\n2. https://git.kernel.org/stable/c/3229c15d6267de8e704b4085df8a82a5af2d63eb\n3. https://git.kernel.org/stable/c/3708acbd5f169ebafe1faa519cb28adc56295546", "creation_timestamp": "2025-05-04T10:18:02.000000Z"}]}