{"vulnerability": "cve-2024-4385", "sightings": [{"uuid": "ed8055de-4deb-43c3-a730-53d0e420e06d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43856", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/3418", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43856 - Linux Kernel dma devres Double Free Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-43856 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndma: fix call order in dmam_free_coherent  \n  \ndmam_free_coherent() frees a DMA allocation, which makes the  \nfreed vaddr available for reuse, then calls devres_destroy()  \nto remove and free the data structure used to track the DMA  \nallocation. Between the two calls, it is possible for a  \nconcurrent task to make an allocation with the same vaddr  \nand add it to the devres list.  \n  \nIf this happens, there will be two entries in the devres list  \nwith the same vaddr and devres_destroy() can free the wrong  \nentry, triggering the WARN_ON() in dmam_match.  \n  \nFix by destroying the devres entry before freeing the DMA  \nallocation.  \n  \n  kokonut //net/encryption  \n    http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:09:10.000000Z"}, {"uuid": "59ea1e4b-965c-4507-9b7e-4a3df141e81e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43855", "type": "seen", "source": "https://t.me/cvedetector/3420", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43855 - \"Linux md: Deadlock between suspend and flush bio\"\", \n  \"Content\": \"CVE ID : CVE-2024-43855 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmd: fix deadlock between mddev_suspend and flush bio  \n  \nDeadlock occurs when mddev is being suspended while some flush bio is in  \nprogress. It is a complex issue.  \n  \nT1. the first flush is at the ending stage, it clears 'mddev->flush_bio'  \n    and tries to submit data, but is blocked because mddev is suspended  \n    by T4.  \nT2. the second flush sets 'mddev->flush_bio', and attempts to queue  \n    md_submit_flush_data(), which is already running (T1) and won't  \n    execute again if on the same CPU as T1.  \nT3. the third flush inc active_io and tries to flush, but is blocked because  \n    'mddev->flush_bio' is not NULL (set by T2).  \nT4. mddev_suspend() is called and waits for active_io dec to 0 which is inc  \n    by T3.  \n  \n  T1  T2  T3  T4  \n  (flush 1) (flush 2) (third 3) (suspend)  \n  md_submit_flush_data  \n   mddev->flush_bio = NULL;  \n   .  \n   .   md_flush_request  \n   .     mddev->flush_bio = bio  \n   .     queue submit_flushes  \n   .   .  \n   .   .  md_handle_request  \n   .   .   active_io + 1  \n   .   .   md_flush_request  \n   .   .    wait !mddev->flush_bio  \n   .   .  \n   .   .    mddev_suspend  \n   .   .     wait !active_io  \n   .   .  \n   .   submit_flushes  \n   .   queue_work md_submit_flush_data  \n   .   //md_submit_flush_data is already running (T1)  \n   .  \n   md_handle_request  \n    wait resume  \n  \nThe root issue is non-atomic inc/dec of active_io during flush process.  \nactive_io is dec before md_submit_flush_data is queued, and inc soon  \nafter md_submit_flush_data() run.  \n  md_flush_request  \n    active_io + 1  \n    submit_flushes  \n      active_io - 1  \n      md_submit_flush_data  \n        md_handle_request  \n        active_io + 1  \n          make_request  \n        active_io - 1  \n  \nIf active_io is dec after md_handle_request() instead of within  \nsubmit_flushes(), make_request() can be called directly intead of  \nmd_handle_request() in md_submit_flush_data(), and active_io will  \nonly inc and dec once in the whole flush process. Deadlock will be  \nfixed.  \n  \nAdditionally, the only difference between fixing the issue and before is  \nthat there is no return error handling of make_request(). But after  \nprevious patch cleaned md_write_start(), make_requst() only return error  \nin raid5_make_request() by dm-raid, see commit 41425f96d7aa (\"dm-raid456,  \nmd/raid456: fix a deadlock for dm-raid456 while io concurrent with  \nreshape)\". Since dm always splits data and flush operation into two  \nseparate io, io size of flush submitted by dm always is 0, make_request()  \nwill not be called in md_submit_flush_data(). To prevent future  \nmodifications from introducing issues, add WARN_ON to ensure  \nmake_request() no error is returned in this context. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:09:15.000000Z"}, {"uuid": "1d59d104-1804-4a9e-9be2-454ce2d761f9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43851", "type": "seen", "source": "https://t.me/cvedetector/3419", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43851 - Xilinx Soc Linux Kernel Device ID Renaming Information Disclosure Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-43851 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsoc: xilinx: rename cpu_number1 to dummy_cpu_number  \n  \nThe per cpu variable cpu_number1 is passed to xlnx_event_handler as  \nargument \"dev_id\", but it is not used in this function. So drop the  \ninitialization of this variable and rename it to dummy_cpu_number.  \nThis patch is to fix the following call trace when the kernel option  \nCONFIG_DEBUG_ATOMIC_SLEEP is enabled:  \n  \nBUG: sleeping function called from invalid context at include/linux/sched/mm.h:274  \n    in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0  \n    preempt_count: 1, expected: 0  \n    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53  \n    Hardware name: Xilinx Versal vmk180 Eval board rev1.1 (QSPI) (DT)  \n    Call trace:  \n     dump_backtrace+0xd0/0xe0  \n     show_stack+0x18/0x40  \n     dump_stack_lvl+0x7c/0xa0  \n     dump_stack+0x18/0x34  \n     __might_resched+0x10c/0x140  \n     __might_sleep+0x4c/0xa0  \n     __kmem_cache_alloc_node+0xf4/0x168  \n     kmalloc_trace+0x28/0x38  \n     __request_percpu_irq+0x74/0x138  \n     xlnx_event_manager_probe+0xf8/0x298  \n     platform_probe+0x68/0xd8 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:09:11.000000Z"}, {"uuid": "731d830b-90cc-4ffb-bdf7-6c2babbd5e2c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43853", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/3417", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43853 - Linux kernel: Cgroup CPUset Use-After-Free\", \n  \"Content\": \"CVE ID : CVE-2024-43853 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ncgroup/cpuset: Prevent UAF in proc_cpuset_show()  \n  \nAn UAF can happen when /proc/cpuset is read as reported in [1].  \n  \nThis can be reproduced by the following methods:  \n1.add an mdelay(1000) before acquiring the cgroup_lock In the  \n cgroup_path_ns function.  \n2.$cat /proc//cpuset   repeatly.  \n3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/  \n$umount /sys/fs/cgroup/cpuset/   repeatly.  \n  \nThe race that cause this bug can be shown as below:  \n  \n(umount)  | (cat /proc//cpuset)  \ncss_release  | proc_cpuset_show  \ncss_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id);  \ncss_free_rwork_fn | cgroup_path_ns(css->cgroup, ...);  \ncgroup_destroy_root | mutex_lock(&cgroup_mutex);  \nrebind_subsystems |  \ncgroup_free_root  |  \n   | // cgrp was freed, UAF  \n   | cgroup_path_ns_locked(cgrp,..);  \n  \nWhen the cpuset is initialized, the root node top_cpuset.css.cgrp  \nwill point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will  \nallocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated  \n&cgroup_root.cgrp. When the umount operation is executed,  \ntop_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.  \n  \nThe problem is that when rebinding to cgrp_dfl_root, there are cases  \nwhere the cgroup_root allocated by setting up the root for cgroup v1  \nis cached. This could lead to a Use-After-Free (UAF) if it is  \nsubsequently freed. The descendant cgroups of cgroup v1 can only be  \nfreed after the css is released. However, the css of the root will never  \nbe released, yet the cgroup_root should be freed when it is unmounted.  \nThis means that obtaining a reference to the css of the root does  \nnot guarantee that css.cgrp->root will not be freed.  \n  \nFix this problem by using rcu_read_lock in proc_cpuset_show().  \nAs cgroup_root is kfree_rcu after commit d23b5c577715  \n(\"cgroup: Make operations on the cgroup root_list RCU safe\"),  \ncss->cgroup won't be freed during the critical section.  \nTo call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to  \nreplace task_get_css with task_css.  \n  \n[1]  \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:09:09.000000Z"}, {"uuid": "2c874663-589d-42d5-99de-48c15166e5de", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43857", "type": "seen", "source": "https://t.me/cvedetector/3416", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43857 - Linux Kernel F2FS Null Pointer Dereference\", \n  \"Content\": \"CVE ID : CVE-2024-43857 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nf2fs: fix null reference error when checking end of zone  \n  \nThis patch fixes a potentially null pointer being accessed by  \nis_end_zone_blkaddr() that checks the last block of a zone  \nwhen f2fs is mounted as a single device. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:09:08.000000Z"}, {"uuid": "14f7cdae-1940-42c7-bd80-e2432728035e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43858", "type": "seen", "source": "https://t.me/cvedetector/3414", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43858 - Linux Kernel jfs Array Index Out of Bounds Buffer Overwrite\", \n  \"Content\": \"CVE ID : CVE-2024-43858 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \njfs: Fix array-index-out-of-bounds in diFree \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:09:03.000000Z"}, {"uuid": "e72878d1-a515-4293-a230-c98af01b059e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43852", "type": "seen", "source": "https://t.me/cvedetector/3413", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43852 - LTC2991 hwmon Array Index Out of Bounds Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-43852 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nhwmon: (ltc2991) re-order conditions to fix off by one bug  \n  \nLTC2991_T_INT_CH_NR is 4.  The st->temp_en[] array has LTC2991_MAX_CHANNEL  \n(4) elements.  Thus if \"channel\" is equal to LTC2991_T_INT_CH_NR then we  \nhave read one element beyond the end of the array.  Flip the conditions  \naround so that we check if \"channel\" is valid before using it as an array  \nindex. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:09:02.000000Z"}, {"uuid": "51bf1634-6f20-474a-a2f7-48ae0072ee8a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43859", "type": "seen", "source": "https://t.me/cvedetector/3412", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43859 - \"F2FS Linux Kernel FSCrypt NULL Pointer Dereference Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-43859 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nf2fs: fix to truncate preallocated blocks in f2fs_file_open()  \n  \nchenyuwen reports a f2fs bug as below:  \n  \nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000011  \n fscrypt_set_bio_crypt_ctx+0x78/0x1e8  \n f2fs_grab_read_bio+0x78/0x208  \n f2fs_submit_page_read+0x44/0x154  \n f2fs_get_read_data_page+0x288/0x5f4  \n f2fs_get_lock_data_page+0x60/0x190  \n truncate_partial_data_page+0x108/0x4fc  \n f2fs_do_truncate_blocks+0x344/0x5f0  \n f2fs_truncate_blocks+0x6c/0x134  \n f2fs_truncate+0xd8/0x200  \n f2fs_iget+0x20c/0x5ac  \n do_garbage_collect+0x5d0/0xf6c  \n f2fs_gc+0x22c/0x6a4  \n f2fs_disable_checkpoint+0xc8/0x310  \n f2fs_fill_super+0x14bc/0x1764  \n mount_bdev+0x1b4/0x21c  \n f2fs_mount+0x20/0x30  \n legacy_get_tree+0x50/0xbc  \n vfs_get_tree+0x5c/0x1b0  \n do_new_mount+0x298/0x4cc  \n path_mount+0x33c/0x5fc  \n __arm64_sys_mount+0xcc/0x15c  \n invoke_syscall+0x60/0x150  \n el0_svc_common+0xb8/0xf8  \n do_el0_svc+0x28/0xa0  \n el0_svc+0x24/0x84  \n el0t_64_sync_handler+0x88/0xec  \n  \nIt is because inode.i_crypt_info is not initialized during below path:  \n- mount  \n - f2fs_fill_super  \n  - f2fs_disable_checkpoint  \n   - f2fs_gc  \n    - f2fs_iget  \n     - f2fs_truncate  \n  \nSo, let's relocate truncation of preallocated blocks to f2fs_file_open(),  \nafter fscrypt_file_open(). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:09:01.000000Z"}, {"uuid": "2dcdd9ec-bbca-4931-9a40-de830f176827", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43850", "type": "seen", "source": "https://t.me/cvedetector/3411", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43850 - Qualcomm Technologies, Inc. soc qcom Incorrect OPP Table Release\", \n  \"Content\": \"CVE ID : CVE-2024-43850 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsoc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove  \n  \nThe following warning is seen during bwmon_remove due to refcount  \nimbalance, fix this by releasing the OPPs after use.  \n  \nLogs:  \nWARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158  \nHardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT)  \n...  \nCall trace:  \n_opp_table_kref_release+0x150/0x158  \ndev_pm_opp_remove_table+0x100/0x1b4  \ndevm_pm_opp_of_table_release+0x10/0x1c  \ndevm_action_release+0x14/0x20  \ndevres_release_all+0xa4/0x104  \ndevice_unbind_cleanup+0x18/0x60  \ndevice_release_driver_internal+0x1ec/0x228  \ndriver_detach+0x50/0x98  \nbus_remove_driver+0x6c/0xbc  \ndriver_unregister+0x30/0x60  \nplatform_driver_unregister+0x14/0x20  \nbwmon_driver_exit+0x18/0x524 [icc_bwmon]  \n__arm64_sys_delete_module+0x184/0x264  \ninvoke_syscall+0x48/0x118  \nel0_svc_common.constprop.0+0xc8/0xe8  \ndo_el0_svc+0x20/0x2c  \nel0_svc+0x34/0xdc  \nel0t_64_sync_handler+0x13c/0x158  \nel0t_64_sync+0x190/0x194  \n--[ end trace 0000000000000000 ]--- \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:09:00.000000Z"}, {"uuid": "215bbac0-4b9e-400c-a1eb-f4d1871a37ca", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43854", "type": "seen", "source": "https://t.me/cvedetector/3410", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43854 - Linux Kernel Block Metadata Memory Leak Disclosure\", \n  \"Content\": \"CVE ID : CVE-2024-43854 \nPublished : Aug. 17, 2024, 10:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nblock: initialize integrity buffer to zero before writing it to media  \n  \nMetadata added by bio_integrity_prep is using plain kmalloc, which leads  \nto random kernel memory being written media.  For PI metadata this is  \nlimited to the app tag that isn't used by kernel generated metadata,  \nbut for non-PI metadata the entire buffer leaks kernel memory.  \n  \nFix this by adding the __GFP_ZERO flag to allocations for writes. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-17T13:08:59.000000Z"}]}