{"vulnerability": "cve-2024-4670", "sightings": [{"uuid": "84c67aba-7c01-4ccd-afb5-804f5a4fef51", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "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": "db37ba4c-5c0c-46aa-a07a-0fd9a5cbcb10", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "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": "33834db9-1124-4665-bbed-aee8069bdbab", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "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": "022dbebe-0919-4d60-a72a-c36f946b0960", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "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": "8be20894-4c25-4400-ae58-fb084c872221", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "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": "81f8ad9c-90b3-4f80-9678-115e4c86bb50", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46700", "type": "seen", "source": "https://t.me/cvedetector/5546", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46700 - AMDGPU Linux Kernel Buffer Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46700 \nPublished : Sept. 13, 2024, 6:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amdgpu/mes: fix mes ring buffer overflow  \n  \nwait memory room until enough before writing mes packets  \nto avoid ring buffer overflow.  \n  \nv2: squash in sched_hw_submission fix  \n  \n(cherry picked from commit 34e087e8920e635c62e2ed6a758b0cd27f836d13) \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-13T08:45:41.000000Z"}, {"uuid": "6c77079a-497a-4bd5-a667-7f53ed46f1bf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "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": "635acde8-7f3a-447a-84fa-1b3bff709fda", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "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": "079e0037-dd5b-4763-9ced-5bf56ed352d1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "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": "19c0c89d-a82b-4105-a7ef-5c6f6da94f42", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "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": "04fb47d7-b6df-4e73-ad25-f475f771e7e6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "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": "bec8e605-2dad-4667-86ed-b2186daf0e2a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46708", "type": "seen", "source": "https://t.me/cvedetector/5564", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46708 - QCOM Linux Kernel Pin Control Offset Integer Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46708 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npinctrl: qcom: x1e80100: Fix special pin offsets  \n  \nRemove the erroneus 0x100000 offset to prevent the boards from crashing  \non pin state setting, as well as for the intended state changes to take  \neffect. \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": "6649c70c-f4c3-4e9d-b596-c2611328eabc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46707", "type": "seen", "source": "https://t.me/cvedetector/5563", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46707 - KVM VMware Hypervisor Information Disclosure\", \n  \"Content\": \"CVE ID : CVE-2024-46707 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nKVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3  \n  \nOn a system with a GICv3, if a guest hasn't been configured with  \nGICv3 and that the host is not capable of GICv2 emulation,  \na write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.  \n  \nWe therefore try to emulate the SGI access, only to hit a NULL  \npointer as no private interrupt is allocated (no GIC, remember?).  \n  \nThe obvious fix is to give the guest what it deserves, in the  \nshape of a UNDEF exception. \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:02.000000Z"}, {"uuid": "15660fae-88ae-4f33-b590-220323186f53", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46705", "type": "seen", "source": "https://t.me/cvedetector/5562", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46705 - Vulnerability Title: Intel Xeon Edge Linux Kernel Memory Mapping Unauthorized Access\", \n  \"Content\": \"CVE ID : CVE-2024-46705 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/xe: reset mmio mappings with devm  \n  \nSet our various mmio mappings to NULL. This should make it easier to  \ncatch something rogue trying to mess with mmio after device removal. For  \nexample, we might unmap everything and then start hitting some mmio  \naddress which has already been unmamped by us and then remapped by  \nsomething else, causing all kinds of carnage. \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:01.000000Z"}, {"uuid": "1aefc983-c48d-48c2-b27e-1eaa0e76a523", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46704", "type": "seen", "source": "https://t.me/cvedetector/5561", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46704 - Linux Kernel Workqueue: Data Race Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46704 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nworkqueue: Fix spruious data race in __flush_work()  \n  \nWhen flushing a work item for cancellation, __flush_work() knows that it  \nexclusively owns the work item through its PENDING bit. 134874e2eee9  \n(\"workqueue: Allow cancel_work_sync() and disable_work() from atomic  \ncontexts on BH work items\") added a read of @work->data to determine whether  \nto use busy wait for BH work items that are being canceled. While the read  \nis safe when @from_cancel, @work->data was read before testing @from_cancel  \nto simplify code structure:  \n  \n data = *work_data_bits(work);  \n if (from_cancel &&  \n     !WARN_ON_ONCE(data & WORK_STRUCT_PWQ) && (data & WORK_OFFQ_BH)) {  \n  \nWhile the read data was never used if !@from_cancel, this could trigger  \nKCSAN data race detection spuriously:  \n  \n  ==================================================================  \n  BUG: KCSAN: data-race in __flush_work / __flush_work  \n  \n  write to 0xffff8881223aa3e8 of 8 bytes by task 3998 on cpu 0:  \n   instrument_write include/linux/instrumented.h:41 [inline]  \n   ___set_bit include/asm-generic/bitops/instrumented-non-atomic.h:28 [inline]  \n   insert_wq_barrier kernel/workqueue.c:3790 [inline]  \n   start_flush_work kernel/workqueue.c:4142 [inline]  \n   __flush_work+0x30b/0x570 kernel/workqueue.c:4178  \n   flush_work kernel/workqueue.c:4229 [inline]  \n   ...  \n  \n  read to 0xffff8881223aa3e8 of 8 bytes by task 50 on cpu 1:  \n   __flush_work+0x42a/0x570 kernel/workqueue.c:4188  \n   flush_work kernel/workqueue.c:4229 [inline]  \n   flush_delayed_work+0x66/0x70 kernel/workqueue.c:4251  \n   ...  \n  \n  value changed: 0x0000000000400000 -> 0xffff88810006c00d  \n  \nReorganize the code so that @from_cancel is tested before @work->data is  \naccessed. The only problem is triggering KCSAN detection spuriously. This  \nshouldn't need READ_ONCE() or other access qualifiers.  \n  \nNo functional changes. \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:00.000000Z"}]}