CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50285 – ksmbd: check outstanding simultaneous SMB operations
https://notcve.org/view.php?id=CVE-2024-50285
In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the "ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit. • https://git.kernel.org/stable/c/1f993777275cbd8f74765c4f9d9285cb907c9be5 https://git.kernel.org/stable/c/e257ac6fe138623cf59fca8898abdf659dbc8356 https://git.kernel.org/stable/c/0a77d947f599b1f39065015bec99390d0c0022ee •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50283 – ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp
https://notcve.org/view.php?id=CVE-2024-50283
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp(). • https://git.kernel.org/stable/c/f7557bbca40d4ca8bb1c6c940ac6c95078bd0827 https://git.kernel.org/stable/c/c6cdc08c25a868a08068dfc319fa9fce982b8e7f https://git.kernel.org/stable/c/1b6ad475d4ed577d34e0157eb507be00c588bf5c https://git.kernel.org/stable/c/b8fc56fbca7482c1e5c0e3351c6ae78982e25ada •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50282 – drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()
https://notcve.org/view.php?id=CVE-2024-50282
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434) • https://git.kernel.org/stable/c/673bdb4200c092692f83b5f7ba3df57021d52d29 https://git.kernel.org/stable/c/7ccd781794d247589104a791caab491e21218fba https://git.kernel.org/stable/c/17f5f18085acb5e9d8d13d84a4e12bb3aff2bd64 https://git.kernel.org/stable/c/aaf6160a4b7f9ee3cd91aa5b3251f5dbe2170f42 https://git.kernel.org/stable/c/25d7e84343e1235b667cf5226c3934fdf36f0df6 https://git.kernel.org/stable/c/8906728f2fbd6504cb488f4afdd66af28f330a7a https://git.kernel.org/stable/c/2faaee36e6e30f9efc7fa6bcb0bdcbe05c23f51f https://git.kernel.org/stable/c/4d75b9468021c73108b4439794d69e892 •
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 •