CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42101 – drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes
https://notcve.org/view.php?id=CVE-2024-42101
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. A flaw was found in the Linux kernel’s nouveau module. The return value of the drm_mode_duplicate function is not checked in the nouveau_connector_get_modes function in the drivers/gpu/drm/nouveau/nouveau_connector.c file, possibly causing a NULL pointer dereference and resulting in a denial of service. • https://git.kernel.org/stable/c/6ee738610f41b59733f63718f0bdbcba7d3a3f12 https://git.kernel.org/stable/c/9baf60323efa992b7c915094529f0a1882c34e7e https://git.kernel.org/stable/c/e36364f5f3785d054a94e57e971385284886d41a https://git.kernel.org/stable/c/274cba8d2d1b48c72d8bd90e76c9e2dc1aa0a81d https://git.kernel.org/stable/c/f48dd3f19614022f2e1b794fbd169d2b4c398c07 https://git.kernel.org/stable/c/1f32535238493008587a8c5cb17eb2ca097592ef https://git.kernel.org/stable/c/744b229f09134ccd091427a6f9ea6d97302cfdd9 https://git.kernel.org/stable/c/7db5411c5d0bd9c29b8c2ad93c36b5c16 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52888 – media: mediatek: vcodec: Only free buffer VA that is not NULL
https://notcve.org/view.php?id=CVE-2023-52888
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Only free buffer VA that is not NULL In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice. We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings. • https://git.kernel.org/stable/c/5c217253c76c94f76d1df31d0bbdcb88dc07be91 https://git.kernel.org/stable/c/303d01082edaf817ee2df53a40dca9da637a2c04 https://git.kernel.org/stable/c/eb005c801ec70ff4307727bd3bd6e8280169ef32 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42098 – crypto: ecdh - explicitly zeroize private_key
https://notcve.org/view.php?id=CVE-2024-42098
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 entire private_key array first. Note that this patch slightly changes the behavior of this function: previously, if the ecc_gen_privkey failed, the old private_key would remain. Now, the private_key is always zeroized. This behavior is consistent with the case where params.key is set and ecc_is_key_valid fails. • https://git.kernel.org/stable/c/39173b04abda87872b43c331468a4a14f8f05ce8 https://git.kernel.org/stable/c/fd7ef325911eba1b7191b83cb580463242f2090d https://git.kernel.org/stable/c/80575b252ab0358b7e93895b2a510beb3cb3f975 https://git.kernel.org/stable/c/d96187eb8e59b572a8e6a68b6a9837a867ea29df https://git.kernel.org/stable/c/73e5984e540a76a2ee1868b91590c922da8c24c9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42097 – ALSA: emux: improve patch ioctl data validation
https://notcve.org/view.php?id=CVE-2024-42097
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. • https://git.kernel.org/stable/c/40d7def67841343c10f8642a41031fecbb248bab https://git.kernel.org/stable/c/79d9a000f0220cdaba1682d2a23c0d0c61d620a3 https://git.kernel.org/stable/c/d23982ea9aa438f35a8c8a6305943e98a8db90f6 https://git.kernel.org/stable/c/7a18293fd8d8519c2f7a03753bc1583b18e3db69 https://git.kernel.org/stable/c/d0ff2443fcbb472206d45a5d2a90cc694065804e https://git.kernel.org/stable/c/d8f5ce3cb9adf0c72e2ad6089aba02d7a32469c2 https://git.kernel.org/stable/c/87039b83fb7bfd7d0e0499aaa8e6c049906b4d14 https://git.kernel.org/stable/c/89b32ccb12ae67e630c6453d778ec30a5 •
CVSS: 5.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42096 – x86: stop playing stack games in profile_pc()
https://notcve.org/view.php?id=CVE-2024-42096
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 or the KASAN warnings when no serious profiling is done using timers anyway these days. And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF. which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addresses but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame. It causes KASAN unhappiness reported for years by syzkaller [1] and others [2]. With no real practical reason for this any more, just remove the code. Just for historical interest, here's some background commits relating to this code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64") and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc") but the basics of this thing actually goes back to before the git tree. • https://git.kernel.org/stable/c/65ebdde16e7f5da99dbf8a548fb635837d78384e https://git.kernel.org/stable/c/27c3be840911b15a3f24ed623f86153c825b6b29 https://git.kernel.org/stable/c/49c09ca35a5f521d7fa18caf62fdf378f15e8aa4 https://git.kernel.org/stable/c/2d07fea561d64357fb7b3f3751e653bf20306d77 https://git.kernel.org/stable/c/161cef818545ecf980f0e2ebaf8ba7326ce53c2b https://git.kernel.org/stable/c/16222beb9f8e5ceb0beeb5cbe54bef16df501a92 https://git.kernel.org/stable/c/a3b65c8cbc139bfce9541bc81c1bb766e5ba3f68 https://git.kernel.org/stable/c/093d9603b60093a9aaae942db56107f64 • CWE-125: Out-of-bounds Read •