CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42098 – crypto: ecdh - explicitly zeroize private_key
https://notcve.org/view.php?id=CVE-2024-42098
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: crypto: ecdh - explicitly zeroize private_key private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the enti... • https://git.kernel.org/stable/c/39173b04abda87872b43c331468a4a14f8f05ce8 •
CVSS: 4.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42097 – ALSA: emux: improve patch ioctl data validation
https://notcve.org/view.php?id=CVE-2024-42097
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: ALSA: emux: improve patch ioctl data validation In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did. In the Linux kernel, the following vulnerability has been resolved: ALSA: emux: improve patch ioctl data validation In load_data(), make the validation of an... • https://git.kernel.org/stable/c/40d7def67841343c10f8642a41031fecbb248bab •
CVSS: 5.2EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42096 – x86: stop playing stack games in profile_pc()
https://notcve.org/view.php?id=CVE-2024-42096
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: x86: stop playing stack games in profile_pc() The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid. Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity... • https://git.kernel.org/stable/c/65ebdde16e7f5da99dbf8a548fb635837d78384e • CWE-125: Out-of-bounds Read •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42094 – net/iucv: Avoid explicit cpumask var allocation on stack
https://notcve.org/view.php?id=CVE-2024-42094
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: net/iucv: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. In the Linux kernel, the following ... • https://git.kernel.org/stable/c/2b085521be5292016097b5e7ca81b26be3f7098d • CWE-121: Stack-based Buffer Overflow •
CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0CVE-2024-42093 – net/dpaa2: Avoid explicit cpumask var allocation on stack
https://notcve.org/view.php?id=CVE-2024-42093
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. In the Linux kernel, the following... • https://git.kernel.org/stable/c/b2262b3be27cee334a2fa175ae3afb53f38fb0b1 •
CVSS: 3.3EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42087 – drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
https://notcve.org/view.php?id=CVE-2024-42087
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue. In the Linux kernel, the following vulnerability has been resolved: drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that slee... • https://git.kernel.org/stable/c/b71348be1236398be2d04c5e145fd6eaae86a91b •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42080 – RDMA/restrack: Fix potential invalid address access
https://notcve.org/view.php?id=CVE-2024-42080
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: RDMA/restrack: Fix potential invalid address access struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME in ib_create_cq(), while if the module exited but forgot del this rdma_restrack_entry, it would cause a invalid address access in rdma_restrack_clean() when print the owner of this rdma_restrack_entry. These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them. In... • https://git.kernel.org/stable/c/8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42079 – gfs2: Fix NULL pointer dereference in gfs2_log_flush
https://notcve.org/view.php?id=CVE-2024-42079
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix NULL pointer dereference in gfs2_log_flush In gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flush lock to provide exclusion against gfs2_log_flush(). In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL before dereferencing it. Otherwise, we could run into a NULL pointer dereference when outstanding glock work races with an unmount (glock_work_func -> run_queue -> do_xmote -> inode_go_sync -> gfs2_log_flush). In t... • https://git.kernel.org/stable/c/3429ef5f50909cee9e498c50f0c499b9397116ce • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42068 – bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
https://notcve.org/view.php?id=CVE-2024-42068
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() set_memory_ro() can fail, leaving memory unprotected. Check its return and take it into account as an error. Ubuntu Security Notice 7156-1 - Chenyuan Yang discovered that the USB Gadget subsystem in the Linux kernel did not properly check for the device to be enabled before writing. A local attacker could possibly use this to cause a denial of service. Several securi... • https://git.kernel.org/stable/c/a359696856ca9409fb97655c5a8ef0f549cb6e03 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42067 – bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()
https://notcve.org/view.php?id=CVE-2024-42067
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro() set_memory_rox() can fail, leaving memory unprotected. Check return and bail out when bpf_jit_binary_lock_ro() returns an error. In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro() set_memory_rox() can fail, leaving memory unprotected. Check return and bail out wh... • https://git.kernel.org/stable/c/08f6c05feb1db21653e98ca84ea04ca032d014c7 •