{"vulnerability": "CVE-2024-5019", "sightings": [{"uuid": "d661a23b-1f89-4e46-8f66-8065bbedd0c9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50193", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/113446164547181543", "content": "", "creation_timestamp": "2024-11-08T07:31:35.138849Z"}, {"uuid": "d31394d9-03a7-4e51-bd8f-70979b6bb972", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50198", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/113446219504583765", "content": "", "creation_timestamp": "2024-11-08T07:45:33.773937Z"}, {"uuid": "79604f21-8a90-4e27-aa36-73ae395b5a19", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50193", "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": "9f36ee91-cf6f-4dbc-9736-9d7af1f9e9ab", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50195", "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": "35163071-ce1c-4354-88ab-4d786b98f7d7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50194", "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": "d8036981-e8f2-4046-8376-71006025edb5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50195", "type": "seen", "source": "https://bsky.app/profile/o2cloud.bsky.social/post/3me6zzvrufd2z", "content": "", "creation_timestamp": "2026-02-06T13:45:16.252407Z"}, {"uuid": "7b4f2358-3954-40da-aca8-090db6874a31", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50198", "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": "ed280877-9ed6-4739-a2a7-8d7510da4a7f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50199", "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": "c12b8177-cd4d-479b-ae67-938bd292ea27", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50196", "type": "seen", "source": "https://bsky.app/profile/o2cloud.bsky.social/post/3mbynkk7rzk2z", "content": "", "creation_timestamp": "2026-01-09T13:55:34.258070Z"}, {"uuid": "9cdae493-8388-4a39-a7b1-f97e84d782d5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50196", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "a7587f3b-c237-4852-bb38-14eafd144a81", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50191", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "4295d5df-7019-4017-bd11-8079286d66b1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50194", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/10179", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50194 - ARM Linux Big-Endian Uprobes Endianness Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50194 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \narm64: probes: Fix uprobes for big-endian kernels  \n  \nThe arm64 uprobes code is broken for big-endian kernels as it doesn't  \nconvert the in-memory instruction encoding (which is always  \nlittle-endian) into the kernel's native endianness before analyzing and  \nsimulating instructions. This may result in a few distinct problems:  \n  \n* The kernel may may erroneously reject probing an instruction which can  \n  safely be probed.  \n  \n* The kernel may erroneously erroneously permit stepping an  \n  instruction out-of-line when that instruction cannot be stepped  \n  out-of-line safely.  \n  \n* The kernel may erroneously simulate instruction incorrectly dur to  \n  interpretting the byte-swapped encoding.  \n  \nThe endianness mismatch isn't caught by the compiler or sparse because:  \n  \n* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so  \n  the compiler and sparse have no idea these contain a little-endian  \n  32-bit value. The core uprobes code populates these with a memcpy()  \n  which similarly does not handle endianness.  \n  \n* While the uprobe_opcode_t type is an alias for __le32, both  \n  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]  \n  to the similarly-named probe_opcode_t, which is an alias for u32.  \n  Hence there is no endianness conversion warning.  \n  \nFix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and  \nadding the appropriate __le32_to_cpu() conversions prior to consuming  \nthe instruction encoding. The core uprobes copies these fields as opaque  \nranges of bytes, and so is unaffected by this change.  \n  \nAt the same time, remove MAX_UINSN_BYTES and consistently use  \nAARCH64_INSN_SIZE for clarity.  \n  \nTested with the following:  \n  \n| #include   \n| #include   \n|  \n| #define noinline __attribute__((noinline))  \n|  \n| static noinline void *adrp_self(void)  \n| {  \n|         void *addr;  \n|  \n|         asm volatile(  \n|         \"       adrp    %x0, adrp_self\\n\"  \n|         \"       add     %x0, %x0, :lo12:adrp_self\\n\"  \n|         : \"=r\" (addr));  \n| }  \n|  \n|  \n| int main(int argc, char *argv)  \n| {  \n|         void *ptr = adrp_self();  \n|         bool equal = (ptr == adrp_self);  \n|  \n|         printf(\"adrp_self   => %p\\n\"  \n|                \"adrp_self() => %p\\n\"  \n|                \"%s\\n\",  \n|                adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\");  \n|  \n|         return 0;  \n| }  \n  \n.... where the adrp_self() function was compiled to:  \n  \n| 00000000004007e0 :  \n|   4007e0:       90000000        adrp    x0, 400000 <__ehdr_start|   4007e4:       911f8000        add     x0, x0, #0x7e0  \n|   4007e8:       d65f03c0        ret  \n  \nBefore this patch, the ADRP is not recognized, and is assumed to be  \nsteppable, resulting in corruption of the result:  \n  \n| # ./adrp-self  \n| adrp_self   => 0x4007e0  \n| adrp_self() => 0x4007e0  \n| EQUAL  \n| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events  \n| # echo 1 > /sys/kernel/tracing/events/uprobes/enable  \n| # ./adrp-self  \n| adrp_self   => 0x4007e0  \n| adrp_self() => 0xffffffffff7e0  \n| NOT EQUAL  \n  \nAfter this patch, the ADRP is correctly recognized and simulated:  \n  \n| # ./adrp-self  \n| adrp_self   => 0x4007e0  \n| adrp_self() => 0x4007e0  \n| EQUAL  \n| #  \n| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events  \n| # echo 1 > /sys/kernel/tracing/events/uprobes/enable  \n| # ./adrp-self  \n| adrp_self   => 0x4007e0  \n| adrp_self() => 0x4007e0  \n| EQUAL \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:55.000000Z"}, {"uuid": "134673a3-c27f-4ccd-864f-88a712afba0d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50192", "type": "seen", "source": "https://t.me/cvedetector/10181", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50192 - \"GICv4: Affinity Changing Vulnerability in irqchip\"\", \n  \"Content\": \"CVE ID : CVE-2024-50192 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nirqchip/gic-v4: Don't allow a VMOVP on a dying VPE  \n  \nKunkun Jiang reported that there is a small window of opportunity for  \nuserspace to force a change of affinity for a VPE while the VPE has already  \nbeen unmapped, but the corresponding doorbell interrupt still visible in  \n/proc/irq/.  \n  \nPlug the race by checking the value of vmapp_count, which tracks whether  \nthe VPE is mapped ot not, and returning an error in this case.  \n  \nThis involves making vmapp_count common to both GICv4.1 and its v4.0  \nancestor. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:57.000000Z"}, {"uuid": "b29320ce-173d-49c4-a6e1-17ee18c2ab2c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50196", "type": "seen", "source": "https://t.me/cvedetector/10177", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50196 - Linux Kernel Pinctrl Ocelot Improper Interrupt Handling Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50196 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npinctrl: ocelot: fix system hang on level based interrupts  \n  \nThe current implementation only calls chained_irq_enter() and  \nchained_irq_exit() if it detects pending interrupts.  \n  \n```  \nfor (i = 0; i < info->stride; i++) {  \n uregmap_read(info->map, id_reg + 4 * i, \u00ae);  \n if (!reg)  \n  continue;  \n  \n chained_irq_enter(parent_chip, desc);  \n```  \n  \nHowever, in case of GPIO pin configured in level mode and the parent  \ncontroller configured in edge mode, GPIO interrupt might be lowered by the  \nhardware. In the result, if the interrupt is short enough, the parent  \ninterrupt is still pending while the GPIO interrupt is cleared;  \nchained_irq_enter() never gets called and the system hangs trying to  \nservice the parent interrupt.  \n  \nMoving chained_irq_enter() and chained_irq_exit() outside the for loop  \nensures that they are called even when GPIO interrupt is lowered by the  \nhardware.  \n  \nThe similar code with chained_irq_enter() / chained_irq_exit() functions  \nwrapping interrupt checking loop may be found in many other drivers:  \n```  \ngrep -r -A 10 chained_irq_enter drivers/pinctrl  \n``` \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:54.000000Z"}, {"uuid": "c68fdaff-daac-4966-8883-2137c48b69a9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50195", "type": "seen", "source": "https://t.me/cvedetector/10173", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50195 - Linux Kernel posix-clock Tespasteime64 Validation RCE\", \n  \"Content\": \"CVE ID : CVE-2024-50195 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nposix-clock: Fix missing timespec64 check in pc_clock_settime()  \n  \nAs Andrew pointed out, it will make sense that the PTP core  \nchecked timespec64 struct's tv_sec and tv_nsec range before calling  \nptp->info->settime64().  \n  \nAs the man manual of clock_settime() said, if tp.tv_sec is negative or  \ntp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,  \nwhich include dynamic clocks which handles PTP clock, and the condition is  \nconsistent with timespec64_valid(). As Thomas suggested, timespec64_valid()  \nonly check the timespec is valid, but not ensure that the time is  \nin a valid range, so check it ahead using timespec64_valid_strict()  \nin pc_clock_settime() and return -EINVAL if not valid.  \n  \nThere are some drivers that use tp->tv_sec and tp->tv_nsec directly to  \nwrite registers without validity checks and assume that the higher layer  \nhas checked it, which is dangerous and will benefit from this, such as  \nhclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),  \nand some drivers can remove the checks of itself. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:48.000000Z"}, {"uuid": "11751a5f-0eda-4745-ade7-99cb4760fd66", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50193", "type": "seen", "source": "https://t.me/cvedetector/10172", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50193 - Intel CPU Buffer Cleardown Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50193 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nx86/entry_32: Clear CPU buffers after register restore in NMI return  \n  \nCPU buffers are currently cleared after call to exc_nmi, but before  \nregister state is restored. This may be okay for MDS mitigation but not for  \nRDFS. Because RDFS mitigation requires CPU buffers to be cleared when  \nregisters don't have any sensitive data.  \n  \nMove CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:47.000000Z"}, {"uuid": "ce59cadb-58d8-4fb1-8f37-a2a5cd5133f8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50191", "type": "seen", "source": "https://t.me/cvedetector/10171", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50191 - Ext4 Remote Filesystem Freeze Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50191 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \next4: don't set SB_RDONLY after filesystem errors  \n  \nWhen the filesystem is mounted with errors=remount-ro, we were setting  \nSB_RDONLY flag to stop all filesystem modifications. We knew this misses  \nproper locking (sb->s_umount) and does not go through proper filesystem  \nremount procedure but it has been the way this worked since early ext2  \ndays and it was good enough for catastrophic situation damage  \nmitigation. Recently, syzbot has found a way (see link) to trigger  \nwarnings in filesystem freezing because the code got confused by  \nSB_RDONLY changing under its hands. Since these days we set  \nEXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all  \nfilesystem modifications, modifying SB_RDONLY shouldn't be needed. So  \nstop doing that. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:44.000000Z"}, {"uuid": "c32cbc62-1c79-45c8-8217-363bb1ec8d62", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50199", "type": "seen", "source": "https://t.me/cvedetector/10169", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50199 - Linux Kernel HugeTLB Page Table Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50199 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/swapfile: skip HugeTLB pages for unuse_vma  \n  \nI got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The  \nproblem can be reproduced by the following steps:  \n  \n 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.  \n 2. Swapout the above anonymous memory.  \n 3. run swapoff and we will get a bad pud error in kernel message:  \n  \n  mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)  \n  \nWe can tell that pud_clear_bad is called by pud_none_or_clear_bad in  \nunuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never  \nbe freed because we lost it from page table.  We can skip HugeTLB pages  \nfor unuse_vma to fix it. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:42.000000Z"}, {"uuid": "0444923a-8a0a-4dd8-a6e9-49cb65eeab8e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50198", "type": "seen", "source": "https://t.me/cvedetector/10168", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50198 - Linux Kernel IIO Device Pointer Corruption Vulnerability in Veml6030 Driver\", \n  \"Content\": \"CVE ID : CVE-2024-50198 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \niio: light: veml6030: fix IIO device retrieval from embedded device  \n  \nThe dev pointer that is received as an argument in the  \nin_illuminance_period_available_show function references the device  \nembedded in the IIO device, not in the i2c client.  \n  \ndev_to_iio_dev() must be used to accessthe right data. The current  \nimplementation leads to a segmentation fault on every attempt to read  \nthe attribute because indio_dev gets a NULL assignment.  \n  \nThis bug has been present since the first appearance of the driver,  \napparently since the last version (V6) before getting applied. A  \nconstant attribute was used until then, and the last modifications might  \nhave not been tested again. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:42.000000Z"}]}