{"vulnerability": "cve-2024-5001", "sightings": [{"uuid": "edb214e3-4336-435b-a889-8bf63ec595e5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50014", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "2f994edf-ad71-4099-bc0f-fc1e68da5df9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50015", "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": "2de28212-7218-4304-ac3e-021a1f5367c3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50013", "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": "55fb79a1-edc9-4243-b022-29d3331bf9b7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50017", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "d7925290-da70-4e1e-8801-bcf7dff3424d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50015", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "a8b206da-f3b0-4a82-bd49-24ae85b65699", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50010", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "a165c155-0264-4d7a-831f-c90a7f60e49a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-50012", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "4e197208-8f8d-4b04-873f-798783f9cc0d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-50014", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "6f4731b9-d6ba-45dc-bafc-0030e4dcaa3c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-50017", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "c1921320-d292-4f93-b0e3-2f91ee752ef2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50013", "type": "seen", "source": "https://t.me/cvedetector/8536", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50013 - Linux Kernel Exfat Memory Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50013 \nPublished : Oct. 21, 2024, 7:15 p.m. | 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nexfat: fix memory leak in exfat_load_bitmap()  \n  \nIf the first directory entry in the root directory is not a bitmap  \ndirectory entry, 'bh' will not be released and reassigned, which  \nwill cause a memory leak. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:52:42.000000Z"}, {"uuid": "c59759ab-2615-4e85-ab0e-c1db4784441d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50012", "type": "seen", "source": "https://t.me/cvedetector/8535", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50012 - Linux Kernel cpufreq Unknown Hardware Node Reference Count Double Free\", \n  \"Content\": \"CVE ID : CVE-2024-50012 \nPublished : Oct. 21, 2024, 7:15 p.m. | 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ncpufreq: Avoid a bad reference count on CPU node  \n  \nIn the parse_perf_domain function, if the call to  \nof_parse_phandle_with_args returns an error, then the reference to the  \nCPU device node that was acquired at the start of the function would not  \nbe properly decremented.  \n  \nAddress this by declaring the variable with the __free(device_node)  \ncleanup attribute. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:52:38.000000Z"}, {"uuid": "3edeb8e9-5015-451f-8570-05d64ea7b18f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50011", "type": "seen", "source": "https://t.me/cvedetector/8534", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50011 - \"SOC Intel Linux Kernel Stack Buffer Overflow Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-50011 \nPublished : Oct. 21, 2024, 7:15 p.m. | 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item  \n  \nThere is no links_num in struct snd_soc_acpi_mach {}, and we test  \n!link->num_adr as a condition to end the loop in hda_sdw_machine_select().  \nSo an empty item in struct snd_soc_acpi_link_adr array is required. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:52:37.000000Z"}, {"uuid": "09495f55-5e63-44fa-add8-90c13add78bb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50010", "type": "seen", "source": "https://t.me/cvedetector/8533", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50010 - Linux Kernel exec Vulnerability: Unintended Noexec Flag Racial Condition\", \n  \"Content\": \"CVE ID : CVE-2024-50010 \nPublished : Oct. 21, 2024, 7:15 p.m. | 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nexec: don't WARN for racy path_noexec check  \n  \nBoth i_mode and noexec checks wrapped in WARN_ON stem from an artifact  \nof the previous implementation. They used to legitimately check for the  \ncondition, but that got moved up in two commits:  \n633fb6ac3980 (\"exec: move S_ISREG() check earlier\")  \n0fd338b2d2cd (\"exec: move path_noexec() check earlier\")  \n  \nInstead of being removed said checks are WARN_ON'ed instead, which  \nhas some debug value.  \n  \nHowever, the spurious path_noexec check is racy, resulting in  \nunwarranted warnings should someone race with setting the noexec flag.  \n  \nOne can note there is more to perm-checking whether execve is allowed  \nand none of the conditions are guaranteed to still hold after they were  \ntested for.  \n  \nAdditionally this does not validate whether the code path did any perm  \nchecking to begin with -- it will pass if the inode happens to be  \nregular.  \n  \nKeep the redundant path_noexec() check even though it's mindless  \nnonsense checking for guarantee that isn't given so drop the WARN.  \n  \nReword the commentary and do small tidy ups while here.  \n  \n[brauner: keep redundant path_noexec() check] \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:52:36.000000Z"}, {"uuid": "9cc4aa02-d396-4a2d-9464-f9a7f41d0005", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50016", "type": "seen", "source": "https://t.me/cvedetector/8539", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50016 - AMD Linux Kernel Integer Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50016 \nPublished : Oct. 21, 2024, 7:15 p.m. | 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amd/display: Avoid overflow assignment in link_dp_cts  \n  \nsampling_rate is an uint8_t but is assigned an unsigned int, and thus it  \ncan overflow. As a result, sampling_rate is changed to uint32_t.  \n  \nSimilarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should  \nonly be assigned to a value less or equal than 4.  \n  \nThis fixes 2 INTEGER_OVERFLOW issues reported by Coverity. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:52:44.000000Z"}, {"uuid": "403a99e6-7a7d-461e-a6a6-9915b8c681a9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50015", "type": "seen", "source": "https://t.me/cvedetector/8538", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50015 - Linux Kernel Ext4 DAX Inode Size Underflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50015 \nPublished : Oct. 21, 2024, 7:15 p.m. | 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \next4: dax: fix overflowing extents beyond inode size when partially writing  \n  \nThe dax_iomap_rw() does two things in each iteration: map written blocks  \nand copy user data to blocks. If the process is killed by user(See signal  \nhandling in dax_iomap_iter()), the copied data will be returned and added  \non inode size, which means that the length of written extents may exceed  \nthe inode size, then fsck will fail. An example is given as:  \n  \ndd if=/dev/urandom of=file bs=4M count=1  \n dax_iomap_rw  \n  iomap_iter // round 1  \n   ext4_iomap_begin  \n    ext4_iomap_alloc // allocate 0~2M extents(written flag)  \n  dax_iomap_iter // copy 2M data  \n  iomap_iter // round 2  \n   iomap_iter_advance  \n    iter->pos += iter->processed // iter->pos = 2M  \n   ext4_iomap_begin  \n    ext4_iomap_alloc // allocate 2~4M extents(written flag)  \n  dax_iomap_iter  \n   fatal_signal_pending  \n  done = iter->pos - iocb->ki_pos // done = 2M  \n ext4_handle_inode_extension  \n  ext4_update_inode_size // inode size = 2M  \n  \nfsck reports: Inode 13, i_size is 2097152, should be 4194304.  Fix?  \n  \nFix the problem by truncating extents if the written length is smaller  \nthan expected. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:52:43.000000Z"}, {"uuid": "20ce0288-ca61-490a-a514-23cebde154f4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50014", "type": "seen", "source": "https://t.me/cvedetector/8537", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50014 - EXT4 Linux Kernel Spinlock Initialization Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50014 \nPublished : Oct. 21, 2024, 7:15 p.m. | 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \next4: fix access to uninitialised lock in fc replay path  \n  \nThe following kernel trace can be triggered with fstest generic/629 when  \nexecuted against a filesystem with fast-commit feature enabled:  \n  \nINFO: trying to register non-static key.  \nThe code is fine but needs lockdep annotation, or maybe  \nyou didn't initialize this object before use?  \nturning off the locking correctness validator.  \nCPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11  \nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014  \nCall Trace:  \n   \n dump_stack_lvl+0x66/0x90  \n register_lock_class+0x759/0x7d0  \n __lock_acquire+0x85/0x2630  \n ? __find_get_block+0xb4/0x380  \n lock_acquire+0xd1/0x2d0  \n ? __ext4_journal_get_write_access+0xd5/0x160  \n _raw_spin_lock+0x33/0x40  \n ? __ext4_journal_get_write_access+0xd5/0x160  \n __ext4_journal_get_write_access+0xd5/0x160  \n ext4_reserve_inode_write+0x61/0xb0  \n __ext4_mark_inode_dirty+0x79/0x270  \n ? ext4_ext_replay_set_iblocks+0x2f8/0x450  \n ext4_ext_replay_set_iblocks+0x330/0x450  \n ext4_fc_replay+0x14c8/0x1540  \n ? jread+0x88/0x2e0  \n ? rcu_is_watching+0x11/0x40  \n do_one_pass+0x447/0xd00  \n jbd2_journal_recover+0x139/0x1b0  \n jbd2_journal_load+0x96/0x390  \n ext4_load_and_init_journal+0x253/0xd40  \n ext4_fill_super+0x2cc6/0x3180  \n...  \n  \nIn the replay path there's an attempt to lock sbi->s_bdev_wb_lock in  \nfunction ext4_check_bdev_write_error().  Unfortunately, at this point this  \nspinlock has not been initialized yet.  Moving it's initialization to an  \nearlier point in __ext4_fill_super() fixes this splat. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:52:43.000000Z"}, {"uuid": "da51d0e8-405f-4e61-bd6f-1e7a3da1259e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50017", "type": "seen", "source": "https://t.me/cvedetector/8527", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50017 - Linux x86 Identity Mapping Spectre Attack Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50017 \nPublished : Oct. 21, 2024, 7:15 p.m. | 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nx86/mm/ident_map: Use gbpages only where full GB page should be mapped.  \n  \nWhen ident_pud_init() uses only GB pages to create identity maps, large  \nranges of addresses not actually requested can be included in the resulting  \ntable; a 4K request will map a full GB.  This can include a lot of extra  \naddress space past that requested, including areas marked reserved by the  \nBIOS.  That allows processor speculation into reserved regions, that on UV  \nsystems can cause system halts.  \n  \nOnly use GB pages when map creation requests include the full GB page of  \nspace.  Fall back to using smaller 2M pages when only portions of a GB page  \nare included in the request.  \n  \nNo attempt is made to coalesce mapping requests. If a request requires a  \nmap entry at the 2M (pmd) level, subsequent mapping requests within the  \nsame 1G region will also be at the pmd level, even if adjacent or  \noverlapping such requests could have been combined to map a full GB page.  \nExisting usage starts with larger regions and then adds smaller regions, so  \nthis should not have any great consequence. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:52:29.000000Z"}, {"uuid": "9029e618-6566-48c0-93bf-80d1cb69546e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50018", "type": "seen", "source": "https://t.me/cvedetector/8526", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50018 - Linux Kernel Net Device NAPI Overflow\", \n  \"Content\": \"CVE ID : CVE-2024-50018 \nPublished : Oct. 21, 2024, 7:15 p.m. | 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: napi: Prevent overflow of napi_defer_hard_irqs  \n  \nIn commit 6f8b12d661d0 (\"net: napi: add hard irqs deferral feature\")  \nnapi_defer_irqs was added to net_device and napi_defer_irqs_count was  \nadded to napi_struct, both as type int.  \n  \nThis value never goes below zero, so there is not reason for it to be a  \nsigned int. Change the type for both from int to u32, and add an  \noverflow check to sysfs to limit the value to S32_MAX.  \n  \nThe limit of S32_MAX was chosen because the practical limit before this  \npatch was S32_MAX (anything larger was an overflow) and thus there are  \nno behavioral changes introduced. If the extra bit is needed in the  \nfuture, the limit can be raised.  \n  \nBefore this patch:  \n  \n$ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs'  \n$ cat /sys/class/net/eth4/napi_defer_hard_irqs  \n-2147483647  \n  \nAfter this patch:  \n  \n$ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs'  \nbash: line 0: echo: write error: Numerical result out of range  \n  \nSimilarly, /sys/class/net/XXXXX/tx_queue_len is defined as unsigned:  \n  \ninclude/linux/netdevice.h:      unsigned int            tx_queue_len;  \n  \nAnd has an overflow check:  \n  \ndev_change_tx_queue_len(..., unsigned long new_len):  \n  \n  if (new_len != (unsigned int)new_len)  \n          return -ERANGE; \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:52:28.000000Z"}]}