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: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42090 – pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
https://notcve.org/view.php?id=CVE-2024-42090
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock. This patch resolves the issue by releasing pinctrl_maps_mutex before call... • https://git.kernel.org/stable/c/42fed7ba44e4e8c1fb27b28ad14490cb1daff3c7 • CWE-833: Deadlock •
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.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42084 – ftruncate: pass a signed offset
https://notcve.org/view.php?id=CVE-2024-42084
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: ftruncate: pass a signed offset The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB. Changing the type of the compat syscall to the signed compat_off_t changes the behavior so it instead returns -EINVAL. The native entry point, the truncate() syscall and the... • https://git.kernel.org/stable/c/3f6d078d4accfff8b114f968259a060bfdc7c682 • CWE-96: Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection') •
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: 8EXPL: 0CVE-2024-42070 – netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
https://notcve.org/view.php?id=CVE-2024-42070
29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers. This vulnerability allows... • https://git.kernel.org/stable/c/96518518cc417bb0a8c80b9fb736202e28acdf96 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •