CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43855 – md: fix deadlock between mddev_suspend and flush bio
https://notcve.org/view.php?id=CVE-2024-43855
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 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 . . . . • https://git.kernel.org/stable/c/f9f2d957a8ea93c73182aebf7de30935a58c027d https://git.kernel.org/stable/c/530cec617f5a8ba6f26bcbf0d64d75c951d17730 https://git.kernel.org/stable/c/fa2bbff7b0b4e211fec5e5686ef96350690597b5 https://git.kernel.org/stable/c/c4c2345214b66e2505a26fd2ea58839dd7a1d48d 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/611d5cbc0b35a752e657a83eebadf40d8 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43854 – block: initialize integrity buffer to zero before writing it to media
https://notcve.org/view.php?id=CVE-2024-43854
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. • https://git.kernel.org/stable/c/7ba1ba12eeef0aa7113beb16410ef8b7c748e18b 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/ebc0e91ba76dc6544fff9f5b66408b198 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43853 – cgroup/cpuset: Prevent UAF in proc_cpuset_show()
https://notcve.org/view.php?id=CVE-2024-43853
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) 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. • https://git.kernel.org/stable/c/a79a908fd2b080977b45bf103184b81c9d11ad07 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/29ac1d238b3bf126af36037df80d7ecc4 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43851 – soc: xilinx: rename cpu_number1 to dummy_cpu_number
https://notcve.org/view.php?id=CVE-2024-43851
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_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 • https://git.kernel.org/stable/c/01946c3c83b2279fec685abc83f0d7b0468851db https://git.kernel.org/stable/c/4722924e7a6225ebf7b09bd7ac5fafc6e73bd4f8 https://git.kernel.org/stable/c/daed80ed07580e5adc0e6d8bc79933a35154135a https://git.kernel.org/stable/c/548bdbbdcd355f5a844c7122c83c9aab115051fa 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/4a95449dd975e2ea6629a034f3e74b46c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-43850 – soc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove
https://notcve.org/view.php?id=CVE-2024-43850
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove The following warning is seen during bwmon_remove due to refcount imbalance, fix this by releasing the OPPs after use. Logs: WARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158 Hardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT) ... Call trace: _opp_table_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 ]--- • https://git.kernel.org/stable/c/b9c2ae6cac403dee3195fda9eb28d8ee733b225b https://git.kernel.org/stable/c/aad41f4c169bcb800ae88123799bdf8cdec3d366 https://git.kernel.org/stable/c/4100d4d019f8e140be1d4d3a9d8d93c1285f5d1c https://git.kernel.org/stable/c/24086640ab39396eb1a92d1cb1cd2f31b2677c52 •