{"vulnerability": "CVE-2024-4223", "sightings": [{"uuid": "8946f875-22c0-4690-823a-94e9286a2894", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-42239", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "0735e5b8-03e2-4269-928c-9edfeb5643cf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42232", "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": "abf9f6d5-a8ae-4c39-952e-192dfb871bd0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42236", "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": "86501a2f-3260-44f2-af64-a8ec6c70a912", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42231", "type": "seen", "source": "https://t.me/cvedetector/2000", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42231 - \"Btrfs Zoned Mode Advisory Allocation Denial of Service\"\", \n  \"Content\": \"CVE ID : CVE-2024-42231 \nPublished : July 30, 2024, 8:15 a.m. | 20\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbtrfs: zoned: fix calc_available_free_space() for zoned mode  \n  \ncalc_available_free_space() returns the total size of metadata (or  \nsystem) block groups, which can be allocated from unallocated disk  \nspace. The logic is wrong on zoned mode in two places.  \n  \nFirst, the calculation of data_chunk_size is wrong. We always allocate  \none zone as one chunk, and no partial allocation of a zone. So, we  \nshould use zone_size (= data_sinfo->chunk_size) as it is.  \n  \nSecond, the result \"avail\" may not be zone aligned. Since we always  \nallocate one zone as one chunk on zoned mode, returning non-zone size  \naligned bytes will result in less pressure on the async metadata reclaim  \nprocess.  \n  \nThis is serious for the nearly full state with a large zone size device.  \nAllowing over-commit too much will result in less async reclaim work and  \nend up in ENOSPC. We can align down to the zone size to avoid that. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"30 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-30T10:43:11.000000Z"}, {"uuid": "b4e6d577-6d62-4fd1-b9bc-0fadb24e7efd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42238", "type": "seen", "source": "https://t.me/cvedetector/2712", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42238 - \"Broadcom Firmware CS_DSP Buffer Overflow Defect\"\", \n  \"Content\": \"CVE ID : CVE-2024-42238 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfirmware: cs_dsp: Return error if block header overflows file  \n  \nReturn an error from cs_dsp_power_up() if a block header is longer  \nthan the amount of data left in the file.  \n  \nThe previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop  \nwhile there was enough data left in the file for a valid region. This  \nprotected against overrunning the end of the file data, but it didn't  \nabort the file processing with an error. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:56.000000Z"}, {"uuid": "8f6936f7-34a9-4d85-a08e-83fb628ce1db", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42232", "type": "seen", "source": "https://t.me/cvedetector/2711", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42232 - Ceph Monitors Auth and Monmap Use-After-Free vulnerable Vulnerabilities\", \n  \"Content\": \"CVE ID : CVE-2024-42232 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nlibceph: fix race between delayed_work() and ceph_monc_stop()  \n  \nThe way the delayed work is handled in ceph_monc_stop() is prone to  \nraces with mon_fault() and possibly also finish_hunting().  Both of  \nthese can requeue the delayed work which wouldn't be canceled by any of  \nthe following code in case that happens after cancel_delayed_work_sync()  \nruns -- __close_session() doesn't mess with the delayed work in order  \nto avoid interfering with the hunting interval logic.  This part was  \nmissed in commit b5d91704f53e (\"libceph: behave in mon_fault() if  \ncur_mon auth and monc->monmap being  \nparticularly susceptible to quickly being reused.  \n  \nTo fix this:  \n  \n- clear monc->cur_mon and monc->hunting as part of closing the session  \n  in ceph_monc_stop()  \n- bail from delayed_work() if monc->cur_mon is cleared, similar to how  \n  it's done in mon_fault() and finish_hunting() (based on monc->hunting)  \n- call cancel_delayed_work_sync() after the session is closed \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:55.000000Z"}, {"uuid": "6f78f717-5b7d-4e2a-b4cd-4758f83cfd75", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42234", "type": "seen", "source": "https://t.me/cvedetector/2707", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42234 - Linux Kernel Folio Migration Double Free Vulnerability (DD) - memcontrol\", \n  \"Content\": \"CVE ID : CVE-2024-42234 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm: fix crashes from deferred split racing folio migration  \n  \nEven on 6.10-rc6, I've been seeing elusive \"Bad page state\"s (often on  \nflags when freeing, yet the flags shown are not bad: PG_locked had been  \nset and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from  \ndeferred_split_scan()'s folio_put(), and a variety of other BUG and WARN  \nsymptoms implying double free by deferred split and large folio migration.  \n  \n6.7 commit 9bcef5973e31 (\"mm: memcg: fix split queue list crash when large  \nfolio migration\") was right to fix the memcg-dependent locking broken in  \n85ce2c517ade (\"memcontrol: only transfer the memcg data for migration\"),  \nbut missed a subtlety of deferred_split_scan(): it moves folios to its own  \nlocal list to work on them without split_queue_lock, during which time  \nfolio->_deferred_list is not empty, but even the \"right\" lock does nothing  \nto secure the folio and the list it is on.  \n  \nFortunately, deferred_split_scan() is careful to use folio_try_get(): so  \nfolio_migrate_mapping() can avoid the race by folio_undo_large_rmappable()  \nwhile the old folio's reference count is temporarily frozen to 0 - adding  \nsuch a freeze in the !mapping case too (originally, folio lock and  \nunmapping and no swap cache left an anon folio unreachable, so no freezing  \nwas needed there: but the deferred split queue offers a way to reach it). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:48.000000Z"}, {"uuid": "cedf2b63-f314-4645-8f42-a6e688cb30cd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42233", "type": "seen", "source": "https://t.me/cvedetector/2715", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42233 - Linux Kernel PTE Unmap Use-After-Free Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42233 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfilemap: replace pte_offset_map() with pte_offset_map_nolock()  \n  \nThe vmf->ptl in filemap_fault_recheck_pte_none() is still set from  \nhandle_pte_fault().  But at the same time, we did a pte_unmap(vmf->pte).   \nAfter a pte_unmap(vmf->pte) unmap and rcu_read_unlock(), the page table  \nmay be racily changed and vmf->ptl maybe fails to protect the actual page  \ntable.  Fix this by replacing pte_offset_map() with  \npte_offset_map_nolock().  \n  \nAs David said, the PTL pointer might be stale so if we continue to use  \nit infilemap_fault_recheck_pte_none(), it might trigger UAF.  Also, if  \nthe PTL fails, the issue fixed by commit 58f327f2ce80 (\"filemap: avoid  \nunnecessary major faults in filemap_fault()\") might reappear. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:39:32.000000Z"}, {"uuid": "14f0b9b3-ff56-4e3d-b700-15817205ac3b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42237", "type": "seen", "source": "https://t.me/cvedetector/2714", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42237 - Symantec Synphony firmware length validation bypass\", \n  \"Content\": \"CVE ID : CVE-2024-42237 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfirmware: cs_dsp: Validate payload length before processing block  \n  \nMove the payload length check in cs_dsp_load() and cs_dsp_coeff_load()  \nto be done before the block is processed.  \n  \nThe check that the length of a block payload does not exceed the number  \nof remaining bytes in the firwmware file buffer was being done near the  \nend of the loop iteration. However, some code before that check used the  \nlength field without validating it. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:58.000000Z"}, {"uuid": "d94b18cc-db1f-4804-b4df-7836a36cbf13", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42235", "type": "seen", "source": "https://t.me/cvedetector/2713", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42235 - Linux Kernel s390 NULL Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42235 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ns390/mm: Add NULL pointer check to crst_table_free() base_crst_free()  \n  \ncrst_table_free() used to work with NULL pointers before the conversion  \nto ptdescs.  Since crst_table_free() can be called with a NULL pointer  \n(error handling in crst_table_upgrade() add an explicit check.  \n  \nAlso add the same check to base_crst_free() for consistency reasons.  \n  \nIn real life this should not happen, since order two GFP_KERNEL  \nallocations will not fail, unless FAIL_PAGE_ALLOC is enabled and used. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:57.000000Z"}, {"uuid": "eaf25800-dbe2-4eef-8177-21d6e350fc4d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42239", "type": "seen", "source": "https://t.me/cvedetector/2710", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42239 - Linux kernel BPF Deadlock Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42239 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Fail bpf_timer_cancel when callback is being cancelled  \n  \nGiven a schedule:  \n  \ntimer1 cb   timer2 cb  \n  \nbpf_timer_cancel(timer2); bpf_timer_cancel(timer1);  \n  \nBoth bpf_timer_cancel calls would wait for the other callback to finish  \nexecuting, introducing a lockup.  \n  \nAdd an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps  \ntrack of all in-flight cancellation requests for a given BPF timer.  \nWhenever cancelling a BPF timer, we must check if we have outstanding  \ncancellation requests, and if so, we must fail the operation with an  \nerror (-EDEADLK) since cancellation is synchronous and waits for the  \ncallback to finish executing. This implies that we can enter a deadlock  \nsituation involving two or more timer callbacks executing in parallel  \nand attempting to cancel one another.  \n  \nNote that we avoid incrementing the cancelling counter for the target  \ntimer (the one being cancelled) if bpf_timer_cancel is not invoked from  \na callback, to avoid spurious errors. The whole point of detecting  \ncur->cancelling and returning -EDEADLK is to not enter a busy wait loop  \n(which may or may not lead to a lockup). This does not apply in case the  \ncaller is in a non-callback context, the other side can continue to  \ncancel as it sees fit without running into errors.  \n  \nBackground on prior attempts:  \n  \nEarlier versions of this patch used a bool 'cancelling' bit and used the  \nfollowing pattern under timer->lock to publish cancellation status.  \n  \nlock(t->lock);  \nt->cancelling = true;  \nmb();  \nif (cur->cancelling)  \n return -EDEADLK;  \nunlock(t->lock);  \nhrtimer_cancel(t->timer);  \nt->cancelling = false;  \n  \nThe store outside the critical section could overwrite a parallel  \nrequests t->cancelling assignment to true, to ensure the parallely  \nexecuting callback observes its cancellation status.  \n  \nIt would be necessary to clear this cancelling bit once hrtimer_cancel  \nis done, but lack of serialization introduced races. Another option was  \nexplored where bpf_timer_start would clear the bit when (re)starting the  \ntimer under timer->lock. This would ensure serialized access to the  \ncancelling bit, but may allow it to be cleared before in-flight  \nhrtimer_cancel has finished executing, such that lockups can occur  \nagain.  \n  \nThus, we choose an atomic counter to keep track of all outstanding  \ncancellation requests and use it to prevent lockups in case callbacks  \nattempt to cancel each other while executing in parallel. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:54.000000Z"}, {"uuid": "ea8e78d2-3337-4a37-9765-5bc89f74b78a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42230", "type": "seen", "source": "https://t.me/cvedetector/1998", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42230 - \"IBM PowerPC pSeries Real-Mode Interrupt Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-42230 \nPublished : July 30, 2024, 8:15 a.m. | 20\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npowerpc/pseries: Fix scv instruction crash with kexec  \n  \nkexec on pseries disables AIL (reloc_on_exc), required for scv  \ninstruction support, before other CPUs have been shut down. This means  \nthey can execute scv instructions after AIL is disabled, which causes an  \ninterrupt at an unexpected entry location that crashes the kernel.  \n  \nChange the kexec sequence to disable AIL after other CPUs have been  \nbrought down.  \n  \nAs a refresher, the real-mode scv interrupt vector is 0x17000, and the  \nfixed-location head code probably couldn't easily deal with implementing  \nsuch high addresses so it was just decided not to support that interrupt  \nat all. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"30 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-30T10:43:09.000000Z"}]}