Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
e_kref_release+0x150/0x158 dev_pm_opp_remove_table+0x100/0x1b4 devm_pm_opp_of_table_release+0x10/0x1c devm_action_release+0x14/0x20 devres_release_all+0xa4/0x104 device_unbind_cleanup+0x18/0x60 device_release_driver_internal+0x1ec/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 bwmon_driver_exit+0x18/0x524 [icc_bwmon] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x34/0xdc el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 --[ end trace 0000000000000000 ]--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https:
+0x190/0x194 --[ end trace 0000000000000000 ]--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/aad41f4c169bcb800ae88123799bdf8cdec3d366 - https://git.kernel.org/stable/c/4100d4d019f8e140be1d4d3a9d8d93c1285f5d1c - https://git.kernel.org/stable/c/24086640ab39396eb1a92d1cb1cd2f31b2677c52
CVE ID: CVE-2024-43851 State: PUBLISHED Published: 2024-08-17T09:22:09.159Z Last Updated: 2025-11-03T22:05:45.955Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: rename cpu_number1 to dummy_cpu_number The per cpu variable cpu_number1 is passed to xlnx_event_handler as argument "dev_id", but it is not used in this function. So drop the initialization of this variable and rename it to dummy_cpu_number. This patch is to fix the following call trace when the kernel option CONFIG_DEBUG_ATOMIC_SLEEP is enabled: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 in_atomic(): 1, irqs_disable
enabled: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53 Hardware name: Xilinx Versal vmk180 Eval board rev1.1 (QSPI) (DT) Call trace: dump_backtrace+0xd0/0xe0 show_stack+0x18/0x40 dump_stack_lvl+0x7c/0xa0 dump_stack+0x18/0x34 __might_resched+0x10c/0x140 __might_sleep+0x4c/0xa0 __kmem_cache_alloc_node+0xf4/0x168 kmalloc_trace+0x28/0x38 __request_percpu_irq+0x74/0x138 xlnx_event_manager_probe+0xf8/0x298 platform_probe+0x68/0xd8 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: Re
probe+0xf8/0x298 platform_probe+0x68/0xd8 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a5e507fadab76393cbc12344ebd65a417a09aa46 - https://git.kernel.org/stable/c/a96e60a6ea6818fd37b1853283a512c49af38cf5 - https://git.kernel.org/stable/c/f762acdaff9e54688be16e6c832c73a61533c1df - https://git.kernel.org/stable/c/4a95449dd975e2ea6629a034f3e74b46c9634916
CVE ID: CVE-2024-43852 State: PUBLISHED Published: 2024-08-17T09:22:09.844Z Last Updated: 2025-05-04T09:27:42.849Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: hwmon: (ltc2991) re-order conditions to fix off by one bug LTC2991_T_INT_CH_NR is 4. The st->temp_en[] array has LTC2991_MAX_CHANNEL (4) elements. Thus if "channel" is equal to LTC2991_T_INT_CH_NR then we have read one element beyond the end of the array. Flip the conditions around so that we check if "channel" is valid before using it as an array index. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c180311c0a520692e2d
ex. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c180311c0a520692e2d0e9ca44dcd6c2ff1b41c4 - https://git.kernel.org/stable/c/99bf7c2eccff82760fa23ce967cc67c8c219c6a6
CVE ID: CVE-2024-43853 State: PUBLISHED Published: 2024-08-17T09:22:10.534Z Last Updated: 2025-11-03T22:05:48.844Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Prevent UAF in proc_cpuset_show() An UAF can happen when /proc/cpuset is read as reported in [1]. This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function. 2.$cat /proc/<pid>/cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly. The race that cause this bug can be shown as below: (umount) | (cat /proc/<pid>/cpuset)
sys/fs/cgroup/cpuset/ repeatly. The race that cause this bug can be shown as below: (umount) | (cat /proc/<pid>/cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...); cgroup_destroy_root | mutex_lock(&cgroup_mutex); rebind_subsystems | cgroup_free_root | | // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..); When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &cgroup_root.cgrp. When the umount operation is executed, top_cpuset.cs
top_cpuset.css.cgrp will point to the allocated &cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp. The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgroup_root should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed. Fi
his means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed. Fix this problem by using rcu_read_lock in proc_cpuset_show(). As cgroup_root is kfree_rcu after commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe"), css->cgroup won't be freed during the critical section. To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to replace task_get_css with task_css. [1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/27d6dbdc6485d68075a0ebf8544d6425c1ed84bb - https://g
VE Program Container: References: - https://git.kernel.org/stable/c/27d6dbdc6485d68075a0ebf8544d6425c1ed84bb - https://git.kernel.org/stable/c/10aeaa47e4aa2432f29b3e5376df96d7dac5537a - https://git.kernel.org/stable/c/688325078a8b5badd6e07ae22b27cd04e9947aec - https://git.kernel.org/stable/c/4e8d6ac8fc9f843e940ab7389db8136634e07989 - https://git.kernel.org/stable/c/29a8d4e02fd4840028c38ceb1536cc8f82a257d4 - https://git.kernel.org/stable/c/96226fbed566f3f686f53a489a29846f2d538080 - https://git.kernel.org/stable/c/29ac1d238b3bf126af36037df80d7ecc4822341e - https://git.kernel.org/stable/c/1be59c97c83ccd67a519d8a49486b3a8a73ca28a
CVE ID: CVE-2024-43854 State: PUBLISHED Published: 2024-08-17T09:22:11.297Z Last Updated: 2025-11-03T22:05:51.729Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: initialize integrity buffer to zero before writing it to media Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Progra
by adding the __GFP_ZERO flag to allocations for writes. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9f4af4cf08f9a0329ade3d938f55d2220c40d0a6 - https://git.kernel.org/stable/c/129f95948a96105c1fad8e612c9097763e88ac5f - https://git.kernel.org/stable/c/3fd11fe4f20756b4c0847f755a64cd96f8c6a005 - https://git.kernel.org/stable/c/cf6b45ea7a8df0f61bded1dc4a8561ac6ad143d2 - https://git.kernel.org/stable/c/d418313bd8f55c079a7da12651951b489a638ac1 - https://git.kernel.org/stable/c/23a19655fb56f241e592041156dfb1c6d04da644 - https://git.kernel.org/stable/c/ebc0e91ba76dc6544fff9f5b66408b1982806a00 - https://git.kernel.org/stabl
dfb1c6d04da644 - https://git.kernel.org/stable/c/ebc0e91ba76dc6544fff9f5b66408b1982806a00 - https://git.kernel.org/stable/c/899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f
CVE ID: CVE-2024-43855 State: PUBLISHED Published: 2024-08-17T09:22:11.985Z Last Updated: 2025-11-03T22:05:53.192Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: fix deadlock between mddev_suspend and flush bio Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue. T1. the first flush is at the ending stage, it clears 'mddev->flush_bio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flush_bio', and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU a
and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc active_io and tries to flush, but is blocked because 'mddev->flush_bio' is not NULL (set by T2). T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc by T3. T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request . mddev->flush_bio = bio . queue submit_flushes . . . . md_handle_request . . active_io + 1 . . md_flush_request . . wait !mddev->flush_bio . . . . mddev_suspend . . wait !active_io . . . submit_flushes . queue_work md_submit_flush_data . //md_submit_
lush_bio . . . . mddev_suspend . . wait !active_io . . . submit_flushes . queue_work md_submit_flush_data . //md_submit_flush_data is already running (T1) . md_handle_request wait resume The root issue is non-atomic inc/dec of active_io during flush process. active_io is dec before md_submit_flush_data is queued, and inc soon after md_submit_flush_data() run. md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1 If active_io is dec after md_handle_request() instead of within submit_flushes(), make_request() can be called directly intead of md_handle_request() in md_submit_flush_data(), and active_io will on
(), make_request() can be called directly intead of md_handle_request() in md_submit_flush_data(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed. Additionally, the only difference between fixing the issue and before is that there is no return error handling of make_request(). But after previous patch cleaned md_write_start(), make_requst() only return error in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, make_request() will not be
data and flush operation into two separate io, io size of flush submitted by dm always is 0, make_request() will not be called in md_submit_flush_data(). To prevent future modifications from introducing issues, add WARN_ON to ensure make_request() no error is returned in this context. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/32226070813140234b6c507084738e8e8385c5c6 - https://git.kernel.org/stable/c/2d0738a8322bf4e5bfe693d16b3111928a9ccfbf - https://git.kernel.org/stable/c/ca963eefbc3331222b6121baa696d49ba2008811 - https://git.kernel.org/stable/c/611d5cbc0b35a752e657a83eebadf40d814d006b
CVE ID: CVE-2024-43856 State: PUBLISHED Published: 2024-08-17T09:24:26.560Z Last Updated: 2025-11-03T22:05:56.178Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() c
he devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/fe2d246080f035e0af5793cb79067ba125e4fb63 - https://git.kernel.org/stable/c/2f7bbdc744f2e7051d1cb47c8e082162df1923c9 - https://git.kernel.org/stable/c/257193083e8f43907e99ea633820fc2b3bcd24c7 - https://git.kernel.org/stable/c/87b34c8c94e29fa01d744
git.kernel.org/stable/c/257193083e8f43907e99ea633820fc2b3bcd24c7 - https://git.kernel.org/stable/c/87b34c8c94e29fa01d744e5147697f592998d954 - https://git.kernel.org/stable/c/f993a4baf6b622232e4c190d34c220179e5d61eb - https://git.kernel.org/stable/c/1fe97f68fce1ba24bf823bfb0eb0956003473130 - https://git.kernel.org/stable/c/22094f5f52e7bc16c5bf9613365049383650b02e - https://git.kernel.org/stable/c/28e8b7406d3a1f5329a03aa25a43aa28e087cb20
CVE ID: CVE-2024-43857 State: PUBLISHED Published: 2024-08-17T09:24:27.279Z Last Updated: 2025-05-04T09:27:49.588Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null reference error when checking end of zone This patch fixes a potentially null pointer being accessed by is_end_zone_blkaddr() that checks the last block of a zone when f2fs is mounted as a single device. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b98777309756ebe15cc9ad4e8ab64bbfaf878a3f - https://git.kernel.org/stable/c/381cbe85592c78fbaeb3e770e3e9f3bfa3e67efb - https://git.kernel.org/stable/c/c82bc1a
a3f - https://git.kernel.org/stable/c/381cbe85592c78fbaeb3e770e3e9f3bfa3e67efb - https://git.kernel.org/stable/c/c82bc1ab2a8a5e73d9728e80c4c2ed87e8921a38
CVE ID: CVE-2024-43858 State: PUBLISHED Published: 2024-08-17T09:24:27.976Z Last Updated: 2025-11-03T22:05:59.215Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: Fix array-index-out-of-bounds in diFree Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/55b732c8b09b41148eaab2fa8e31b0af47671e00 - https://git.kernel.org/stable/c/9b3a4345957f5372041bc4f59de322f62653e862 - https://git.kernel.org/stable/c/538a27c8048f081a5ddd286f886eb986fbbc7f80 - https://git.kernel.org/stable/c/63f7fdf733add82f126ea00e2e48f6eba15ac4b9 - https://git.kernel.org/stable/c/8d8f9a
7f80 - https://git.kernel.org/stable/c/63f7fdf733add82f126ea00e2e48f6eba15ac4b9 - https://git.kernel.org/stable/c/8d8f9a477de0d7962342eedf2a599215b7c63d28 - https://git.kernel.org/stable/c/ff14eadc278663cac69d57d3ca7fb2f394e1f8a7 - https://git.kernel.org/stable/c/6aa6892a90a5a7fabffe5692ab9f06a7a46c6e42 - https://git.kernel.org/stable/c/f73f969b2eb39ad8056f6c7f3a295fa2f85e313a
CVE ID: CVE-2024-43859 State: PUBLISHED Published: 2024-08-17T09:24:28.672Z Last Updated: 2025-11-03T22:06:00.688Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to truncate preallocated blocks in f2fs_file_open() chenyuwen reports a f2fs bug as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000011 fscrypt_set_bio_crypt_ctx+0x78/0x1e8 f2fs_grab_read_bio+0x78/0x208 f2fs_submit_page_read+0x44/0x154 f2fs_get_read_data_page+0x288/0x5f4 f2fs_get_lock_data_page+0x60/0x190 truncate_partial_data_page+0x108/0x4fc f2fs_do_truncate_blocks+0x344/0x5f0 f2fs_truncate_blocks+0x6c/0x134 f2fs_trun
190 truncate_partial_data_page+0x108/0x4fc f2fs_do_truncate_blocks+0x344/0x5f0 f2fs_truncate_blocks+0x6c/0x134 f2fs_truncate+0xd8/0x200 f2fs_iget+0x20c/0x5ac do_garbage_collect+0x5d0/0xf6c f2fs_gc+0x22c/0x6a4 f2fs_disable_checkpoint+0xc8/0x310 f2fs_fill_super+0x14bc/0x1764 mount_bdev+0x1b4/0x21c f2fs_mount+0x20/0x30 legacy_get_tree+0x50/0xbc vfs_get_tree+0x5c/0x1b0 do_new_mount+0x298/0x4cc path_mount+0x33c/0x5fc __arm64_sys_mount+0xcc/0x15c invoke_syscall+0x60/0x150 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0xa0 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec It is because inode.i_crypt_info is not initialized during below path: - mount - f2fs_fill_super - f2fs_disable_checkpoint - f2fs_gc -
inode.i_crypt_info is not initialized during below path: - mount - f2fs_fill_super - f2fs_disable_checkpoint - f2fs_gc - f2fs_iget - f2fs_truncate So, let's relocate truncation of preallocated blocks to f2fs_file_open(), after fscrypt_file_open(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/5f04969136db674f133781626e0b692c5f2bf2f0 - https://git.kernel.org/stable/c/f44a25a8bfe0c15d33244539696cd9119cf44d18 - https://git.kernel.org/stable/c/3ba0ae885215b325605ff7ebf6de12ac2adf204d - https://git.kernel.org/stable/c/298b1e4182d657c3e388adcc29477904e9600ed5
CVE ID: CVE-2024-43860 State: PUBLISHED Published: 2024-08-17T09:24:29.436Z Last Updated: 2025-11-03T22:06:05.559Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Skip over memory region when node value is NULL In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts number of phandles. But phandles may be empty. So of_parse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. [Fixed title to fit within the prescribed 70-75 charcters] Addition
x Verification Center (linuxtesting.org) with SVACE. [Fixed title to fit within the prescribed 70-75 charcters] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6884fd0283e0831be153fb8d82d9eda8a55acaaa - https://git.kernel.org/stable/c/84beb7738459cac0ff9f8a7c4654b8ff82a702c0 - https://git.kernel.org/stable/c/6b50462b473fdccdc0dfad73001147e40ff19a66 - https://git.kernel.org/stable/c/4e13b7c23988c0a13fdca92e94296a3bc2ff9f21 - https://git.kernel.org/stable/c/9a17cf8b2ce483fa75258bc2cdcf628f24bcf5f8 - https://git.kernel.org/stable/c/6c9ea3547fad252fe9ae5d3ed7e066e2085bf3a2 - https://git.kernel.org/stable/c/c877a5f5268d4ab8
ps://git.kernel.org/stable/c/6c9ea3547fad252fe9ae5d3ed7e066e2085bf3a2 - https://git.kernel.org/stable/c/c877a5f5268d4ab8224b9c9fbce3d746e4e72bc9 - https://git.kernel.org/stable/c/2fa26ca8b786888673689ccc9da6094150939982
CVE ID: CVE-2024-43861 State: PUBLISHED Published: 2024-08-20T21:37:53.029Z Last Updated: 2025-11-03T22:06:08.508Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: fix memory leak for not ip packets Free the unused skb when not ip packets arrive. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3c90a69533b5bba73401ef884d033ea49ee99662 - https://git.kernel.org/stable/c/37c093449704017870604994ba9b813cdb9475a4 - https://git.kernel.org/stable/c/e87f52225e04a7001bf55bbd7a330fa4252327b5 - https://git.kernel.org/stable/c/c4251a3deccad852b27e606
t.kernel.org/stable/c/e87f52225e04a7001bf55bbd7a330fa4252327b5 - https://git.kernel.org/stable/c/c4251a3deccad852b27e60625f31fba6cc14372f - https://git.kernel.org/stable/c/da518cc9b64df391795d9952aed551e0f782e446 - https://git.kernel.org/stable/c/f2c353227de14b0289298ffc3ba92058c4768384 - https://git.kernel.org/stable/c/c6c5b91424fafc0f83852d961c10c7e43a001882 - https://git.kernel.org/stable/c/7ab107544b777c3bd7feb9fe447367d8edd5b202
CVE ID: CVE-2024-43862 State: PUBLISHED Published: 2024-08-20T23:45:26.643Z Last Updated: 2025-05-04T09:27:55.603Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex The carrier_lock spinlock protects the carrier detection. While it is held, framer_get_status() is called which in turn takes a mutex. This is not correct and can lead to a deadlock. A run with PROVE_LOCKING enabled detected the issue: [ BUG: Invalid wait context ] ... c204ddbc (&framer->mutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78 other info that might help us debug this: context-{4:4} 2 locks hel
>mutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78 other info that might help us debug this: context-{4:4} 2 locks held by ifconfig/146: #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, at: devinet_ioctl+0x12c/0x664 #1: c2006a40 (&qmc_hdlc->carrier_lock){....}-{2:2}, at: qmc_hdlc_framer_set_carrier+0x30/0x98 Avoid the spinlock usage and convert carrier_lock to a mutex. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f223d2b4acb7a45a6e0581cb380e1af1a6dc7ab9 - https://git.kernel.org/stable/c/c4d6a347ba7babdf9d90a0eb24048c266cae0532
CVE ID: CVE-2024-43863 State: PUBLISHED Published: 2024-08-20T23:45:27.756Z Last Updated: 2025-11-03T22:06:09.978Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and remove
a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: -
his fixes KDE stalls/deadlock. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9908dc0d2ef0e4aec8a242c098455729c0e2f017 - https://git.kernel.org/stable/c/9e20d028d8d1deb1e7fed18f22ffc01669cf3237 - https://git.kernel.org/stable/c/3b933b16c996af8adb6bc1b5748a63dfb41a82bc - https://git.kernel.org/stable/c/a8943969f9ead2fd3044fc826140a21622ef830e - https://git.kernel.org/stable/c/c98ab18b9f315ff977c2c65d7c71298ef98be8e3 - https://git.kernel.org/stable/c/e58337100721f3cc0c7424a18730e4f39844934f