{"vulnerability": "CVE-2024-4209", "sightings": [{"uuid": "409ca2b0-60b1-41a3-8af2-435d051b98b8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-42098", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "73cf4581-ebe4-4382-83ce-5cf0e667069b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42092", "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": "d4ce9cdb-4f9c-4b60-802a-714f515c50ec", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42094", "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": "49fe941f-f343-489a-969e-bd2b2892a51f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42095", "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": "3fda728b-1adf-44e3-8906-1aa83fdf8226", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42093", "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": "8e44f468-62dc-4d09-865d-c39c940e5e6d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-42091", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "b1b1f2bf-d303-46b2-a969-3a94ae9a5f4b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42094", "type": "seen", "source": "https://t.me/cvedetector/1909", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42094 - Linux kernel IUCV CPU Mask Stack Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42094 \nPublished : July 29, 2024, 6:15 p.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet/iucv: Avoid explicit cpumask var allocation on stack  \n  \nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask  \nvariable on stack is not recommended since it can cause potential stack  \noverflow.  \n  \nInstead, kernel code should always use *cpumask_var API(s) to allocate  \ncpumask var in config-neutral way, leaving allocation strategy to  \nCONFIG_CPUMASK_OFFSTACK.  \n  \nUse *cpumask_var API(s) to address it. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-29T21:19:28.000000Z"}, {"uuid": "e0f0bed6-5af5-401e-ae91-dccb483d6e2b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42090", "type": "seen", "source": "https://t.me/cvedetector/1894", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42090 - Linux kernel pinctrl Deadlock Primitive-sensitive Information Disclosure\", \n  \"Content\": \"CVE ID : CVE-2024-42090 \nPublished : July 29, 2024, 5:15 p.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER  \n  \nIn create_pinctrl(), pinctrl_maps_mutex is acquired before calling  \nadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()  \ncalls pinctrl_free(). However, pinctrl_free() attempts to acquire  \npinctrl_maps_mutex, which is already held by create_pinctrl(), leading to  \na potential deadlock.  \n  \nThis patch resolves the issue by releasing pinctrl_maps_mutex before  \ncalling pinctrl_free(), preventing the deadlock.  \n  \nThis bug was discovered and resolved using Coverity Static Analysis  \nSecurity Testing (SAST) by Synopsys, Inc. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-29T19:38:56.000000Z"}, {"uuid": "6a1bcce9-0cf4-44df-ba0c-b65cef5838a5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42092", "type": "seen", "source": "https://t.me/cvedetector/1910", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42092 - \"Synopsys Davinci Linux Kernel Out-of-Bounds IRQ Access Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-42092 \nPublished : July 29, 2024, 6:15 p.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ngpio: davinci: Validate the obtained number of IRQs  \n  \nValue of pdata->gpio_unbanked is taken from Device Tree. In case of broken  \nDT due to any error this value can be any. Without this value validation  \nthere can be out of chips->irqs array boundaries access in  \ndavinci_gpio_probe().  \n  \nValidate the obtained nirq value so that it won't exceed the maximum  \nnumber of IRQs per bank.  \n  \nFound by Linux Verification Center (linuxtesting.org) with SVACE. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-29T21:19:29.000000Z"}, {"uuid": "391c4fd2-ba8c-472f-828f-86290e3f37e7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42093", "type": "seen", "source": "https://t.me/cvedetector/1908", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42093 - Linux dpaa2 CPUMASK Stack Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42093 \nPublished : July 29, 2024, 6:15 p.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet/dpaa2: Avoid explicit cpumask var allocation on stack  \n  \nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask  \nvariable on stack is not recommended since it can cause potential stack  \noverflow.  \n  \nInstead, kernel code should always use *cpumask_var API(s) to allocate  \ncpumask var in config-neutral way, leaving allocation strategy to  \nCONFIG_CPUMASK_OFFSTACK.  \n  \nUse *cpumask_var API(s) to address it. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-29T21:19:27.000000Z"}, {"uuid": "41809e54-d1a2-4d30-b6e8-a19c0983a415", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42091", "type": "seen", "source": "https://t.me/cvedetector/1907", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42091 - Oracle XE Linux Kernel Pointer Deref Remote Code Execution Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42091 \nPublished : July 29, 2024, 6:15 p.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/xe: Check pat.ops before dumping PAT settings  \n  \nWe may leave pat.ops unset when running on brand new platform or  \nwhen running as a VF.  While the former is unlikely, the latter  \nis valid (future) use case and will cause NPD when someone will  \ntry to dump PAT settings by debugfs.  \n  \nIt's better to check pointer to pat.ops instead of specific .dump  \nhook, as we have this hook always defined for every .ops variant. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-29T21:19:26.000000Z"}, {"uuid": "d793dd04-6231-4238-8436-7e6a0e51f999", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42095", "type": "seen", "source": "https://t.me/cvedetector/1906", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42095 - Texas Instruments OMAP Serial Driver Interrupt Handling Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42095 \nPublished : July 29, 2024, 6:15 p.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nserial: 8250_omap: Implementation of Errata i2310  \n  \nAs per Errata i2310[0], Erroneous timeout can be triggered,  \nif this Erroneous interrupt is not cleared then it may leads  \nto storm of interrupts, therefore apply Errata i2310 solution.  \n  \n[0]  page 23 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-29T21:19:25.000000Z"}, {"uuid": "ceb6bd12-b75c-4e7e-9db6-c2f1fdaa3a0d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42096", "type": "seen", "source": "https://t.me/cvedetector/1904", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42096 - Linux Kernel x86 Stack Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42096 \nPublished : July 29, 2024, 6:15 p.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nx86: stop playing stack games in profile_pc()  \n  \nThe 'profile_pc()' function is used for timer-based profiling, which  \nisn't really all that relevant any more to begin with, but it also ends  \nup making assumptions based on the stack layout that aren't necessarily  \nvalid.  \n  \nBasically, the code tries to account the time spent in spinlocks to the  \ncaller rather than the spinlock, and while I support that as a concept,  \nit's not worth the code complexity or the KASAN warnings when no serious  \nprofiling is done using timers anyway these days.  \n  \nAnd the code really does depend on stack layout that is only true in the  \nsimplest of cases.  We've lost the comment at some point (I think when  \nthe 32-bit and 64-bit code was unified), but it used to say:  \n  \n Assume the lock function has either no stack frame or a copy  \n of eflags from PUSHF.  \n  \nwhich explains why it just blindly loads a word or two straight off the  \nstack pointer and then takes a minimal look at the values to just check  \nif they might be eflags or the return pc:  \n  \n Eflags always has bits 22 and up cleared unlike kernel addresses  \n  \nbut that basic stack layout assumption assumes that there isn't any lock  \ndebugging etc going on that would complicate the code and cause a stack  \nframe.  \n  \nIt causes KASAN unhappiness reported for years by syzkaller [1] and  \nothers [2].  \n  \nWith no real practical reason for this any more, just remove the code.  \n  \nJust for historical interest, here's some background commits relating to  \nthis code from 2006:  \n  \n  0cb91a229364 (\"i386: Account spinlocks to the caller during profiling for !FP kernels\")  \n  31679f38d886 (\"Simplify profile_pc on x86-64\")  \n  \nand a code unification from 2009:  \n  \n  ef4512882dbe (\"x86: time_32/64.c unify profile_pc\")  \n  \nbut the basics of this thing actually goes back to before the git tree. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-29T21:19:23.000000Z"}, {"uuid": "440b4081-6a47-4415-8f68-658295b858d0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42098", "type": "seen", "source": "https://t.me/cvedetector/1903", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42098 - Here's a potential title for this vulnerability: \"Linux Kernel Crypto ECrypto Private Key Zeroization Failure\"\", \n  \"Content\": \"CVE ID : CVE-2024-42098 \nPublished : July 29, 2024, 6:15 p.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ncrypto: ecdh - explicitly zeroize private_key  \n  \nprivate_key is overwritten with the key parameter passed in by the  \ncaller (if present), or alternatively a newly generated private key.  \nHowever, it is possible that the caller provides a key (or the newly  \ngenerated key) which is shorter than the previous key. In that  \nscenario, some key material from the previous key would not be  \noverwritten. The easiest solution is to explicitly zeroize the entire  \nprivate_key array first.  \n  \nNote that this patch slightly changes the behavior of this function:  \npreviously, if the ecc_gen_privkey failed, the old private_key would  \nremain. Now, the private_key is always zeroized. This behavior is  \nconsistent with the case where params.key is set and ecc_is_key_valid  \nfails. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-29T21:19:22.000000Z"}, {"uuid": "dd6171a6-8f0b-428c-ba4d-82c7f1687125", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42097", "type": "seen", "source": "https://t.me/cvedetector/1901", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42097 - ALSA emux Patch Validation Buffer Overflow\", \n  \"Content\": \"CVE ID : CVE-2024-42097 \nPublished : July 29, 2024, 6:15 p.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nALSA: emux: improve patch ioctl data validation  \n  \nIn load_data(), make the validation of and skipping over the main info  \nblock match that in load_guspatch().  \n  \nIn load_guspatch(), add checking that the specified patch length matches  \nthe actually supplied data, like load_data() already did. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-29T21:19:17.000000Z"}]}