https://db.gcve.eu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Thu, 22 Oct 2026 01:21:31 +0000 https://db.gcve.eu/sighting/022dbebe-0919-4d60-a72a-c36f946b0960/export {"uuid": "022dbebe-0919-4d60-a72a-c36f946b0960", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2024-46705", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"} {"uuid": "022dbebe-0919-4d60-a72a-c36f946b0960", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2024-46705", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"} https://db.gcve.eu/sighting/022dbebe-0919-4d60-a72a-c36f946b0960/export Thu, 19 Mar 2026 00:00:00 +0000 https://db.gcve.eu/sighting/8be20894-4c25-4400-ae58-fb084c872221/export {"uuid": "8be20894-4c25-4400-ae58-fb084c872221", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46702", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"} {"uuid": "8be20894-4c25-4400-ae58-fb084c872221", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46702", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"} https://db.gcve.eu/sighting/8be20894-4c25-4400-ae58-fb084c872221/export Wed, 03 Dec 2025 14:14:49 +0000 https://db.gcve.eu/sighting/84c67aba-7c01-4ccd-afb5-804f5a4fef51/export {"uuid": "84c67aba-7c01-4ccd-afb5-804f5a4fef51", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46707", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"} {"uuid": "84c67aba-7c01-4ccd-afb5-804f5a4fef51", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46707", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"} https://db.gcve.eu/sighting/84c67aba-7c01-4ccd-afb5-804f5a4fef51/export Wed, 03 Dec 2025 14:14:49 +0000 https://db.gcve.eu/sighting/db37ba4c-5c0c-46aa-a07a-0fd9a5cbcb10/export {"uuid": "db37ba4c-5c0c-46aa-a07a-0fd9a5cbcb10", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46702", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} {"uuid": "db37ba4c-5c0c-46aa-a07a-0fd9a5cbcb10", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46702", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} https://db.gcve.eu/sighting/db37ba4c-5c0c-46aa-a07a-0fd9a5cbcb10/export Thu, 14 Aug 2025 10:00:00 +0000 https://db.gcve.eu/sighting/33834db9-1124-4665-bbed-aee8069bdbab/export {"uuid": "33834db9-1124-4665-bbed-aee8069bdbab", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46707", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} {"uuid": "33834db9-1124-4665-bbed-aee8069bdbab", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46707", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} https://db.gcve.eu/sighting/33834db9-1124-4665-bbed-aee8069bdbab/export Thu, 14 Aug 2025 10:00:00 +0000 https://db.gcve.eu/sighting/6c77079a-497a-4bd5-a667-7f53ed46f1bf/export {"uuid": "6c77079a-497a-4bd5-a667-7f53ed46f1bf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46706", "type": "seen", "source": "https://t.me/cvedetector/5571", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46706 - \"Freescale FSL LPUART UARTSTAT Hang on Linux Console Boot\"\", \n \"Content\": \"CVE ID : CVE-2024-46706 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ntty: serial: fsl_lpuart: mark last busy before uart_add_one_port \n \nWith \"earlycon initcall_debug=1 loglevel=8\" in bootargs, kernel \nsometimes boot hang. It is because normal console still is not ready, \nbut runtime suspend is called, so early console putchar will hang \nin waiting TRDE set in UARTSTAT. \n \nThe lpuart driver has auto suspend delay set to 3000ms, but during \nuart_add_one_port, a child device serial ctrl will added and probed with \nits pm runtime enabled(see serial_ctrl.c). \nThe runtime suspend call path is: \ndevice_add \n |-> bus_probe_device \n |->device_initial_probe \n |->__device_attach \n |-> pm_runtime_get_sync(dev->parent); \n |-> pm_request_idle(dev); \n |-> pm_runtime_put(dev->parent); \n \nSo in the end, before normal console ready, the lpuart get runtime \nsuspended. And earlycon putchar will hang. \n \nTo address the issue, mark last busy just after pm_runtime_enable, \nthree seconds is long enough to switch from bootconsole to normal \nconsole. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:14.000000Z"} {"uuid": "6c77079a-497a-4bd5-a667-7f53ed46f1bf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46706", "type": "seen", "source": "https://t.me/cvedetector/5571", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46706 - \"Freescale FSL LPUART UARTSTAT Hang on Linux Console Boot\"\", \n \"Content\": \"CVE ID : CVE-2024-46706 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ntty: serial: fsl_lpuart: mark last busy before uart_add_one_port \n \nWith \"earlycon initcall_debug=1 loglevel=8\" in bootargs, kernel \nsometimes boot hang. It is because normal console still is not ready, \nbut runtime suspend is called, so early console putchar will hang \nin waiting TRDE set in UARTSTAT. \n \nThe lpuart driver has auto suspend delay set to 3000ms, but during \nuart_add_one_port, a child device serial ctrl will added and probed with \nits pm runtime enabled(see serial_ctrl.c). \nThe runtime suspend call path is: \ndevice_add \n |-> bus_probe_device \n |->device_initial_probe \n |->__device_attach \n |-> pm_runtime_get_sync(dev->parent); \n |-> pm_request_idle(dev); \n |-> pm_runtime_put(dev->parent); \n \nSo in the end, before normal console ready, the lpuart get runtime \nsuspended. And earlycon putchar will hang. \n \nTo address the issue, mark last busy just after pm_runtime_enable, \nthree seconds is long enough to switch from bootconsole to normal \nconsole. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:14.000000Z"} https://db.gcve.eu/sighting/6c77079a-497a-4bd5-a667-7f53ed46f1bf/export Fri, 13 Sep 2024 09:36:14 +0000 https://db.gcve.eu/sighting/635acde8-7f3a-447a-84fa-1b3bff709fda/export {"uuid": "635acde8-7f3a-447a-84fa-1b3bff709fda", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46702", "type": "seen", "source": "https://t.me/cvedetector/5569", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46702 - Thunderbolt XDomain Unlocking Denial of Service\", \n \"Content\": \"CVE ID : CVE-2024-46702 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nthunderbolt: Mark XDomain as unplugged when router is removed \n \nI noticed that when we do discrete host router NVM upgrade and it gets \nhot-removed from the PCIe side as a result of NVM firmware authentication, \nif there is another host connected with enabled paths we hang in tearing \nthem down. This is due to fact that the Thunderbolt networking driver \nalso tries to cleanup the paths and ends up blocking in \ntb_disconnect_xdomain_paths() waiting for the domain lock. \n \nHowever, at this point we already cleaned the paths in tb_stop() so \nthere is really no need for tb_disconnect_xdomain_paths() to do that \nanymore. Furthermore it already checks if the XDomain is unplugged and \nbails out early so take advantage of that and mark the XDomain as \nunplugged when we remove the parent router. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:13.000000Z"} {"uuid": "635acde8-7f3a-447a-84fa-1b3bff709fda", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46702", "type": "seen", "source": "https://t.me/cvedetector/5569", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46702 - Thunderbolt XDomain Unlocking Denial of Service\", \n \"Content\": \"CVE ID : CVE-2024-46702 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nthunderbolt: Mark XDomain as unplugged when router is removed \n \nI noticed that when we do discrete host router NVM upgrade and it gets \nhot-removed from the PCIe side as a result of NVM firmware authentication, \nif there is another host connected with enabled paths we hang in tearing \nthem down. This is due to fact that the Thunderbolt networking driver \nalso tries to cleanup the paths and ends up blocking in \ntb_disconnect_xdomain_paths() waiting for the domain lock. \n \nHowever, at this point we already cleaned the paths in tb_stop() so \nthere is really no need for tb_disconnect_xdomain_paths() to do that \nanymore. Furthermore it already checks if the XDomain is unplugged and \nbails out early so take advantage of that and mark the XDomain as \nunplugged when we remove the parent router. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:13.000000Z"} https://db.gcve.eu/sighting/635acde8-7f3a-447a-84fa-1b3bff709fda/export Fri, 13 Sep 2024 09:36:13 +0000 https://db.gcve.eu/sighting/079e0037-dd5b-4763-9ced-5bf56ed352d1/export {"uuid": "079e0037-dd5b-4763-9ced-5bf56ed352d1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46703", "type": "seen", "source": "https://t.me/cvedetector/5568", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46703 - Linux Kernel PM Domain Crash Vulnerability in 8250 OMAP Serial Driver.\", \n \"Content\": \"CVE ID : CVE-2024-46703 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nRevert \"serial: 8250_omap: Set the console genpd always on if no console suspend\" \n \nThis reverts commit 68e6939ea9ec3d6579eadeab16060339cdeaf940. \n \nKevin reported that this causes a crash during suspend on platforms that \ndont use PM domains. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:09.000000Z"} {"uuid": "079e0037-dd5b-4763-9ced-5bf56ed352d1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46703", "type": "seen", "source": "https://t.me/cvedetector/5568", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46703 - Linux Kernel PM Domain Crash Vulnerability in 8250 OMAP Serial Driver.\", \n \"Content\": \"CVE ID : CVE-2024-46703 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nRevert \"serial: 8250_omap: Set the console genpd always on if no console suspend\" \n \nThis reverts commit 68e6939ea9ec3d6579eadeab16060339cdeaf940. \n \nKevin reported that this causes a crash during suspend on platforms that \ndont use PM domains. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:09.000000Z"} https://db.gcve.eu/sighting/079e0037-dd5b-4763-9ced-5bf56ed352d1/export Fri, 13 Sep 2024 09:36:09 +0000 https://db.gcve.eu/sighting/19c0c89d-a82b-4105-a7ef-5c6f6da94f42/export {"uuid": "19c0c89d-a82b-4105-a7ef-5c6f6da94f42", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46701", "type": "seen", "source": "https://t.me/cvedetector/5566", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46701 - \"tmpfs Infinite Directory Read Vulnerability\"\", \n \"Content\": \"CVE ID : CVE-2024-46701 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nlibfs: fix infinite directory reads for offset dir \n \nAfter we switch tmpfs dir operations from simple_dir_operations to \nsimple_offset_dir_operations, every rename happened will fill new dentry \nto dest dir's maple tree(&SHMEM_I(inode)->dir_offsets->mt) with a free \nkey starting with octx->newx_offset, and then set newx_offset equals to \nfree key + 1. This will lead to infinite readdir combine with rename \nhappened at the same time, which fail generic/736 in xfstests(detail show \nas below). \n \n1. create 5000 files(1 2 3...) under one dir \n2. call readdir(man 3 readdir) once, and get one entry \n3. rename(entry, \"TEMPFILE\"), then rename(\"TEMPFILE\", entry) \n4. loop 2~3, until readdir return nothing or we loop too many \n times(tmpfs break test with the second condition) \n \nWe choose the same logic what commit 9b378f6ad48cf (\"btrfs: fix infinite \ndirectory reads\") to fix it, record the last_index when we open dir, and \ndo not emit the entry which index >= last_index. The file->private_data \nnow used in offset dir can use directly to do this, and we also update \nthe last_index when we llseek the dir file. \n \n[brauner: only update last_index after seek when offset is zero like Jan suggested] \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:07.000000Z"} {"uuid": "19c0c89d-a82b-4105-a7ef-5c6f6da94f42", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46701", "type": "seen", "source": "https://t.me/cvedetector/5566", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46701 - \"tmpfs Infinite Directory Read Vulnerability\"\", \n \"Content\": \"CVE ID : CVE-2024-46701 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nlibfs: fix infinite directory reads for offset dir \n \nAfter we switch tmpfs dir operations from simple_dir_operations to \nsimple_offset_dir_operations, every rename happened will fill new dentry \nto dest dir's maple tree(&SHMEM_I(inode)->dir_offsets->mt) with a free \nkey starting with octx->newx_offset, and then set newx_offset equals to \nfree key + 1. This will lead to infinite readdir combine with rename \nhappened at the same time, which fail generic/736 in xfstests(detail show \nas below). \n \n1. create 5000 files(1 2 3...) under one dir \n2. call readdir(man 3 readdir) once, and get one entry \n3. rename(entry, \"TEMPFILE\"), then rename(\"TEMPFILE\", entry) \n4. loop 2~3, until readdir return nothing or we loop too many \n times(tmpfs break test with the second condition) \n \nWe choose the same logic what commit 9b378f6ad48cf (\"btrfs: fix infinite \ndirectory reads\") to fix it, record the last_index when we open dir, and \ndo not emit the entry which index >= last_index. The file->private_data \nnow used in offset dir can use directly to do this, and we also update \nthe last_index when we llseek the dir file. \n \n[brauner: only update last_index after seek when offset is zero like Jan suggested] \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:07.000000Z"} https://db.gcve.eu/sighting/19c0c89d-a82b-4105-a7ef-5c6f6da94f42/export Fri, 13 Sep 2024 09:36:07 +0000 https://db.gcve.eu/sighting/04fb47d7-b6df-4e73-ad25-f475f771e7e6/export {"uuid": "04fb47d7-b6df-4e73-ad25-f475f771e7e6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46709", "type": "seen", "source": "https://t.me/cvedetector/5565", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46709 - VMWare Graphics Driver Direct Memory Mapping Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-46709 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/vmwgfx: Fix prime with external buffers \n \nMake sure that for external buffers mapping goes through the dma_buf \ninterface instead of trying to access pages directly. \n \nExternal buffers might not provide direct access to readable/writable \npages so to make sure the bo's created from external dma_bufs can be \nread dma_buf interface has to be used. \n \nFixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't \ntrigger this due to the fact that virtual machines will not have \nmultiple GPUs but it enables better test coverage in IGT. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:06.000000Z"} {"uuid": "04fb47d7-b6df-4e73-ad25-f475f771e7e6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46709", "type": "seen", "source": "https://t.me/cvedetector/5565", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46709 - VMWare Graphics Driver Direct Memory Mapping Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-46709 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/vmwgfx: Fix prime with external buffers \n \nMake sure that for external buffers mapping goes through the dma_buf \ninterface instead of trying to access pages directly. \n \nExternal buffers might not provide direct access to readable/writable \npages so to make sure the bo's created from external dma_bufs can be \nread dma_buf interface has to be used. \n \nFixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't \ntrigger this due to the fact that virtual machines will not have \nmultiple GPUs but it enables better test coverage in IGT. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:06.000000Z"} https://db.gcve.eu/sighting/04fb47d7-b6df-4e73-ad25-f475f771e7e6/export Fri, 13 Sep 2024 09:36:06 +0000