CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43856 – dma: fix call order in dmam_free_coherent
https://notcve.org/view.php?id=CVE-2024-43856
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() 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 • https://git.kernel.org/stable/c/9ac7849e35f705830f7b016ff272b0ff1f7ff759 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/87b34c8c94e29fa01d744e5147697f592998d954 https://git.kernel.org/stable/c/f993a4baf6b622232e4c190d34c220179e5d61eb https://git.kernel.org/stable/c/1fe97f68fce1ba24bf823bfb0eb0956003473130 https://git.kernel.org/stable/c/22094f5f52e7bc16c5bf9613365049383 •
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: -EPSS: 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 •
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: 2EXPL: 0CVE-2024-43852 – hwmon: (ltc2991) re-order conditions to fix off by one bug
https://notcve.org/view.php?id=CVE-2024-43852
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. • https://git.kernel.org/stable/c/2b9ea4262ae9114b0b86ac893b4d6175d8520001 https://git.kernel.org/stable/c/c180311c0a520692e2d0e9ca44dcd6c2ff1b41c4 https://git.kernel.org/stable/c/99bf7c2eccff82760fa23ce967cc67c8c219c6a6 •