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: 3EXPL: 0CVE-2024-50281 – KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation
https://notcve.org/view.php?id=CVE-2024-50281
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls. • https://git.kernel.org/stable/c/0e28bf61a5f9ab30be3f3b4eafb8d097e39446bb https://git.kernel.org/stable/c/9e3b266afcfe4294e84496f50f006f029d3100db https://git.kernel.org/stable/c/c75e0272289eae18c5379518a9c56ef31d65cc7d https://git.kernel.org/stable/c/04de7589e0a95167d803ecadd115235ba2c14997 •
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 •