CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-50280 – dm cache: fix flushing uninitialized delayed_work on cache_ctr error
https://notcve.org/view.php?id=CVE-2024-50280
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb ("dm cache: Fix UAF in destroy()")) as cache_dtr is not changed. • https://git.kernel.org/stable/c/6a3e412c2ab131c54945327a7676b006f000a209 https://git.kernel.org/stable/c/6a459d8edbdbe7b24db42a5a9f21e6aa9e00c2aa https://git.kernel.org/stable/c/034cbc8d3b47a56acd89453c29632a9c117de09d https://git.kernel.org/stable/c/993406104d2b28fe470126a062ad37a1e21e792e https://git.kernel.org/stable/c/4d20032dd90664de09f2902a7ea49ae2f7771746 https://git.kernel.org/stable/c/2f097dfac7579fd84ff98eb1d3acd41d53a485f3 https://git.kernel.org/stable/c/2b17026685a270b2beaf1cdd9857fcedd3505c7e https://git.kernel.org/stable/c/d2a0b298ebf83ab6236f66788a3541e91 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50279 – dm cache: fix out-of-bounds access to the dirty bitset when resizing
https://notcve.org/view.php?id=CVE-2024-50279
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented. • https://git.kernel.org/stable/c/f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 https://git.kernel.org/stable/c/4fa4feb873cea0e9d6ff883b37cca6f33169d8b4 https://git.kernel.org/stable/c/8501e38dc9e0060814c4085815fc83da3e6d43bf https://git.kernel.org/stable/c/ee1f74925717ab36f6a091104c170639501ce818 https://git.kernel.org/stable/c/ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f https://git.kernel.org/stable/c/56507203e1b6127967ec2b51fb0b23a0d4af1334 https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de85 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50278 – dm cache: fix potential out-of-bounds access on the first resume
https://notcve.org/view.php?id=CVE-2024-50278
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume. • https://git.kernel.org/stable/c/f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 https://git.kernel.org/stable/c/e492f71854ce03474d49e87fd98b8df1f7cd1d2d https://git.kernel.org/stable/c/2222b0929d00e2d13732b799b63be391b5de4492 https://git.kernel.org/stable/c/483b7261b35a9d369082ab298a6670912243f0be https://git.kernel.org/stable/c/fdef3b94dfebd57e3077a578b6e309a2bb6fa688 https://git.kernel.org/stable/c/c52ec00cb2f9bebfada22edcc0db385b910a1cdb https://git.kernel.org/stable/c/036dd6e3d2638103e0092864577ea1d091466b86 https://git.kernel.org/stable/c/13ed3624c6ef283acefa4cc42cc8ae54f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50277 – dm: fix a crash if blk_alloc_disk fails
https://notcve.org/view.php?id=CVE-2024-50277
In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement "md->disk->private_data = NULL;". • https://git.kernel.org/stable/c/d7aec2a06730b774a97caaf48cbbc58330a85829 https://git.kernel.org/stable/c/fed13a5478680614ba97fc87e71f16e2e197912e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50276 – net: vertexcom: mse102x: Fix possible double free of TX skb
https://notcve.org/view.php?id=CVE-2024-50276
In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660) • https://git.kernel.org/stable/c/2f207cbf0dd44278af2aa3ff0fc95b0f97cc4e4c https://git.kernel.org/stable/c/2cf0e77f5a0aa1ff336aa71743eda55c73902187 https://git.kernel.org/stable/c/1325e838089da25217f4b403318a270fcdf88f34 https://git.kernel.org/stable/c/91c9daa21f3ff8668f9e1d6c860024ce7ad64137 https://git.kernel.org/stable/c/1f26339b2ed63d1e8e18a18674fb73a392f3660e •