CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-39466 – thermal/drivers/qcom/lmh: Check for SCM availability at probe
https://notcve.org/view.php?id=CVE-2024-39466
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/qcom/lmh: Check for SCM availability at probe Up until now, the necessary scm availability check has not been performed, leading to possible null pointer dereferences (which did happen for me on RB1). Fix that. • https://git.kernel.org/stable/c/53bca371cdf7addc1e93e1b99285b3d3935685ec https://git.kernel.org/stable/c/2226b145afa5e13cb60dbe77fb20fb0666a1caf3 https://git.kernel.org/stable/c/560d69c975072974c11434ca6953891e74c1a665 https://git.kernel.org/stable/c/0a47ba94ec3d8f782b33e3d970cfcb769b962464 https://git.kernel.org/stable/c/aa1a0807b4a76b44fb6b58a7e9087cd4b18ab41b https://git.kernel.org/stable/c/d9d3490c48df572edefc0b64655259eefdcbb9be •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39464 – media: v4l: async: Fix notifier list entry init
https://notcve.org/view.php?id=CVE-2024-39464
In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Fix notifier list entry init struct v4l2_async_notifier has several list_head members, but only waiting_list and done_list are initialized. notifier_entry was kept 'zeroed' leading to an uninitialized list_head. This results in a NULL-pointer dereference if csi2_async_register() fails, e.g. node for remote endpoint is disabled, and returns -ENOTCONN. The following calls to v4l2_async_nf_unregister() results in a NULL pointer dereference. Add the missing list head initializer. • https://git.kernel.org/stable/c/b8ec754ae4c563f6aab8c0cb47aeb2eae67f1da3 https://git.kernel.org/stable/c/a80d1da923f671c1e6a14e8417cd2f117b27a442 https://git.kernel.org/stable/c/44f6d619c30f0c65fcdd2b6eba70fdb4460d87ad https://git.kernel.org/stable/c/6d8acd02c4c6a8f917eefac1de2e035521ca119d •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2024-39463 – 9p: add missing locking around taking dentry fid list
https://notcve.org/view.php?id=CVE-2024-39463
In the Linux kernel, the following vulnerability has been resolved: 9p: add missing locking around taking dentry fid list Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it: UAF thread: refcount_t: addition on 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Freed by: p9_fid_destroy (inlined) p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 The problem is that d_fsdata was not accessed under d_lock, because d_release() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fs_remove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible. This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the handling of the p9_fid object. • https://git.kernel.org/stable/c/154372e67d4053e56591245eb413686621941333 https://git.kernel.org/stable/c/3bb6763a8319170c2d41c4232c8e7e4c37dcacfb https://git.kernel.org/stable/c/cb299cdba09f46f090b843d78ba26b667d50a456 https://git.kernel.org/stable/c/f0c5c944c6d8614c19e6e9a97fd2011dcd30e8f5 https://git.kernel.org/stable/c/fe17ebf22feb4ad7094d597526d558a49aac92b4 https://git.kernel.org/stable/c/c898afdc15645efb555acb6d85b484eb40a45409 https://www.zerodayinitiative.com/advisories/ZDI-24-1194 • CWE-416: Use After Free •
CVSS: 9.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39462 – clk: bcm: dvp: Assign ->num before accessing ->hws
https://notcve.org/view.php?id=CVE-2024-39462
In the Linux kernel, the following vulnerability has been resolved: clk: bcm: dvp: Assign ->num before accessing ->hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in clk_dvp_probe() due to ->num being assigned after ->hws has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2 index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') Move the ->num initialization to before the first access of ->hws, which clears up the warning. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: bcm: dvp: Assign ->num before accessing ->hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") anotó el miembro hws de 'struct clk_hw_onecell_data' con __counted_by, que informa al sanitizante de los límites sobre la cantidad de elementos en hws, para que pueda advertir cuando se accede a hws fuera de los límites. Como se señaló en ese cambio, el miembro __counted_by debe inicializarse con la cantidad de elementos antes de que ocurra el primer acceso a la matriz; de lo contrario, habrá una advertencia de cada acceso antes de la inicialización porque la cantidad de elementos es cero. • https://git.kernel.org/stable/c/f316cdff8d677db9ad9c90acb44c4cd535b0ee27 https://git.kernel.org/stable/c/0dc913217fb79096597005bba9ba738e2db5cd02 https://git.kernel.org/stable/c/a1dd92fca0d6b58b55ed0484f75d4205dbb77010 https://git.kernel.org/stable/c/9368cdf90f52a68120d039887ccff74ff33b4444 • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39461 – clk: bcm: rpi: Assign ->num before accessing ->hws
https://notcve.org/view.php?id=CVE-2024-39461
In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Assign ->num before accessing ->hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in raspberrypi_discover_clocks() due to ->num being assigned after ->hws has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4 index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') Move the ->num initialization to before the first access of ->hws, which clears up the warning. • https://git.kernel.org/stable/c/f316cdff8d677db9ad9c90acb44c4cd535b0ee27 https://git.kernel.org/stable/c/9562dbe5cdbb16ac887d27ef6f179980bb99193c https://git.kernel.org/stable/c/cdf9c7871d58d3df59d2775982e3533adb8ec920 https://git.kernel.org/stable/c/6dc445c1905096b2ed4db1a84570375b4e00cc0f •