CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42236 – usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
https://notcve.org/view.php?id=CVE-2024-42236
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Prevent OOB read/write in usb_string_copy() Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form `if (str[0 - 1] == '\n') followed closely by an OOB write in the form `str[0 - 1] = '\0'`. There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short. • https://git.kernel.org/stable/c/a444c3fc264119801575ab086e03fb4952f23fd0 https://git.kernel.org/stable/c/c95fbdde87e39e5e0ae27f28bf6711edfb985caa https://git.kernel.org/stable/c/e8474a10c535e6a2024c3b06e37e4a3a23beb490 https://git.kernel.org/stable/c/72b8ee0d9826e8ed00e0bdfce3e46b98419b37ce https://git.kernel.org/stable/c/2d16f63d8030903e5031853e79d731ee5d474e70 https://git.kernel.org/stable/c/d1205033e912f9332c1dbefa812e6ceb0575ce0a https://git.kernel.org/stable/c/eecfefad0953b2f31aaefa058f7f348ff39c4bba https://git.kernel.org/stable/c/6d3c721e686ea6c59e18289b400cc95c7 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42232 – libceph: fix race between delayed_work() and ceph_monc_stop()
https://notcve.org/view.php?id=CVE-2024-42232
In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed • https://git.kernel.org/stable/c/1177afeca833174ba83504688eec898c6214f4bf https://git.kernel.org/stable/c/63e5d035e3a7ab7412a008f202633c5e6a0a28ea https://git.kernel.org/stable/c/34b76d1922e41da1fa73d43b764cddd82ac9733c https://git.kernel.org/stable/c/20cf67dcb7db842f941eff1af6ee5e9dc41796d7 https://git.kernel.org/stable/c/2d33654d40a05afd91ab24c9a73ab512a0670a9a https://git.kernel.org/stable/c/9525af1f58f67df387768770fcf6d6a8f23aee3d https://git.kernel.org/stable/c/33d38c5da17f8db2d80e811b7829d2822c10625e https://git.kernel.org/stable/c/69c7b2fe4c9cc1d3b1186d1c5606627ec •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42229 – crypto: aead,cipher - zeroize key buffer after use
https://notcve.org/view.php?id=CVE-2024-42229
In the Linux kernel, the following vulnerability has been resolved: crypto: aead,cipher - zeroize key buffer after use I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key. • https://git.kernel.org/stable/c/9db8c299a521813630fcb4154298cb60c37f3133 https://git.kernel.org/stable/c/71dd428615375e36523f4d4f7685ddd54113646d https://git.kernel.org/stable/c/28c8d274848feba552e95c5c2a7e3cfe8f15c534 https://git.kernel.org/stable/c/b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb https://git.kernel.org/stable/c/f58679996a831754a356974376f248aa0af2eb8e https://git.kernel.org/stable/c/23e4099bdc3c8381992f9eb975c79196d6755210 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42228 – drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc
https://notcve.org/view.php?id=CVE-2024-42228
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian) • https://git.kernel.org/stable/c/d35cf41c8eb5d9fe95b21ae6ee2910f9ba4878e8 https://git.kernel.org/stable/c/3b505759447637dcccb50cbd98ec6f8d2a04fc46 https://git.kernel.org/stable/c/df02642c21c984303fe34c3f7d72965792fb1a15 https://git.kernel.org/stable/c/da6a85d197888067e8d38b5d22c986b5b5cab712 https://git.kernel.org/stable/c/9ee1534ecdd5b4c013064663502d7fde824d2144 https://git.kernel.org/stable/c/855ae72c20310e5402b2317fc537d911e87537ef https://git.kernel.org/stable/c/f8f120b3de48b8b6bdf8988a9b334c2d61c17440 https://git.kernel.org/stable/c/88a9a467c548d0b3c7761b4fd54a68e70 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42227 – drm/amd/display: Fix overlapping copy within dml_core_mode_programming
https://notcve.org/view.php?id=CVE-2024-42227
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix overlapping copy within dml_core_mode_programming [WHY] &mode_lib->mp.Watermark and &locals->Watermark are the same address. memcpy may lead to unexpected behavior. [HOW] memmove should be used. • https://git.kernel.org/stable/c/9342da15f2491d8600eca89c8e0da08876fb969b https://git.kernel.org/stable/c/f1fd8a0a54e6d23a6d16ee29159f247862460fd1 •