{"vulnerability": "CVE-2024-4684", "sightings": [{"uuid": "9a3d7745-7a7b-4135-a105-9d0b8e5ba9c5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2024-46842", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "af3e69d7-18aa-4f54-b55a-5a3b92d55102", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2024-46843", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "c2bd19b7-8ea3-44d2-b0ca-38a841bb4ba8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2024-46848", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "706cf10f-2fa9-4530-847b-e352fc6cf7d4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46848", "type": "seen", "source": "https://t.me/cvedetector/6528", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46848 - Intel Haswell perf/x86 Linux Kernel PMU Handling Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46848 \nPublished : Sept. 27, 2024, 1:15 p.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nperf/x86/intel: Limit the period on Haswell  \n  \nRunning the ltp test cve-2015-3290 concurrently reports the following  \nwarnings.  \n  \nperfevents: irq loop stuck!  \n  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174  \n  intel_pmu_handle_irq+0x285/0x370  \n  Call Trace:  \n     \n   ? __warn+0xa4/0x220  \n   ? intel_pmu_handle_irq+0x285/0x370  \n   ? __report_bug+0x123/0x130  \n   ? intel_pmu_handle_irq+0x285/0x370  \n   ? __report_bug+0x123/0x130  \n   ? intel_pmu_handle_irq+0x285/0x370  \n   ? report_bug+0x3e/0xa0  \n   ? handle_bug+0x3c/0x70  \n   ? exc_invalid_op+0x18/0x50  \n   ? asm_exc_invalid_op+0x1a/0x20  \n   ? irq_work_claim+0x1e/0x40  \n   ? intel_pmu_handle_irq+0x285/0x370  \n   perf_event_nmi_handler+0x3d/0x60  \n   nmi_handle+0x104/0x330  \n  \nThanks to Thomas Gleixner's analysis, the issue is caused by the low  \ninitial period (1) of the frequency estimation algorithm, which triggers  \nthe defects of the HW, specifically erratum HSW11 and HSW143. (For the  \ndetails, please refer )  \n  \nThe HSW11 requires a period larger than 100 for the INST_RETIRED.ALL  \nevent, but the initial period in the freq mode is 1. The erratum is the  \nsame as the BDM11, which has been supported in the kernel. A minimum  \nperiod of 128 is enforced as well on HSW.  \n  \nHSW143 is regarding that the fixed counter 1 may overcount 32 with the  \nHyper-Threading is enabled. However, based on the test, the hardware  \nhas more issues than it tells. Besides the fixed counter 1, the message  \n'interrupt took too long' can be observed on any counter which was armed  \nwith a period < 32 and two events expired in the same NMI. A minimum  \nperiod of 32 is enforced for the rest of the events.  \nThe recommended workaround code of the HSW143 is not implemented.  \nBecause it only addresses the issue for the fixed counter. It brings  \nextra overhead through extra MSR writing. No related overcounting issue  \nhas been reported so far. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-27T15:53:36.000000Z"}, {"uuid": "3251ae6d-a6a5-4bb2-adb1-599eab19cfe5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46847", "type": "seen", "source": "https://t.me/cvedetector/6529", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46847 - Linux Kernel: Out-of-Bounds Access Vulnerability in vmalloc Module\", \n  \"Content\": \"CVE ID : CVE-2024-46847 \nPublished : Sept. 27, 2024, 1:15 p.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm: vmalloc: ensure vmap_block is initialised before adding to queue  \n  \nCommit 8c61291fd850 (\"mm: fix incorrect vbq reference in  \npurge_fragmented_block\") extended the 'vmap_block' structure to contain a  \n'cpu' field which is set at allocation time to the id of the initialising  \nCPU.  \n  \nWhen a new 'vmap_block' is being instantiated by new_vmap_block(), the  \npartially initialised structure is added to the local 'vmap_block_queue'  \nxarray before the 'cpu' field has been initialised.  If another CPU is  \nconcurrently walking the xarray (e.g.  via vm_unmap_aliases()), then it  \nmay perform an out-of-bounds access to the remote queue thanks to an  \nuninitialised index.  \n  \nThis has been observed as UBSAN errors in Android:  \n  \n | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP  \n |  \n | Call trace:  \n |  purge_fragmented_block+0x204/0x21c  \n |  _vm_unmap_aliases+0x170/0x378  \n |  vm_unmap_aliases+0x1c/0x28  \n |  change_memory_common+0x1dc/0x26c  \n |  set_memory_ro+0x18/0x24  \n |  module_enable_ro+0x98/0x238  \n |  do_init_module+0x1b0/0x310  \n  \nMove the initialisation of 'vb->cpu' in new_vmap_block() ahead of the  \naddition to the xarray. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-27T15:53:37.000000Z"}, {"uuid": "3a5cad47-c720-42fb-936e-d04ae9d82304", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46846", "type": "seen", "source": "https://t.me/cvedetector/6527", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46846 - Rockchip spi unbalanced Power Management\", \n  \"Content\": \"CVE ID : CVE-2024-46846 \nPublished : Sept. 27, 2024, 1:15 p.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nspi: rockchip: Resolve unbalanced runtime PM / system PM handling  \n  \nCommit e882575efc77 (\"spi: rockchip: Suspend and resume the bus during  \nNOIRQ_SYSTEM_SLEEP_PM ops\") stopped respecting runtime PM status and  \nsimply disabled clocks unconditionally when suspending the system. This  \ncauses problems when the device is already runtime suspended when we go  \nto sleep -- in which case we double-disable clocks and produce a  \nWARNing.  \n  \nSwitch back to pm_runtime_force_{suspend,resume}(), because that still  \nseems like the right thing to do, and the aforementioned commit makes no  \nexplanation why it stopped using it.  \n  \nAlso, refactor some of the resume() error handling, because it's not  \nactually a good idea to re-disable clocks on failure. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-27T15:53:35.000000Z"}, {"uuid": "1300a915-d014-4153-93bf-ecdc2c73ada1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46848", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "28fde4fe-9e42-49dd-bd15-17d598ad8b6c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-4684", "type": "seen", "source": "Telegram/2g-ymLsVDtEPvz-syEE6M5Kg7EEgN-HyU6FbaFwEI7sGLG6a", "content": "", "creation_timestamp": "2025-02-19T22:21:29.000000Z"}, {"uuid": "4fcdf2bf-74db-424f-8178-46c8d89f2257", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46840", "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": "7dbb087b-bc44-420c-9079-d01c46bf9900", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46844", "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": "61028680-fe21-4539-b240-b746022e1a45", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46841", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "d01f2ffa-ad18-4c83-aea3-046ccd8ef730", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-46842", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}]}