CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42261 – drm/v3d: Validate passed in drm syncobj handles in the timestamp extension
https://notcve.org/view.php?id=CVE-2024-42261
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Validate passed in drm syncobj handles in the timestamp extension If userspace provides an unknown or invalid handle anywhere in the handle array the rest of the driver will not handle that well. Fix it by checking handle was looked up successfully or otherwise fail the extension by jumping into the existing unwind. (cherry picked from commit 8d1276d1b8f738c3afe1457d4dff5cc66fc848a3) • https://git.kernel.org/stable/c/9ba0ff3e083f6a4a0b6698f06bfff74805fefa5f https://git.kernel.org/stable/c/5c56f104edd02a537e9327dc543574e55713e1d7 https://git.kernel.org/stable/c/023d22e8bb0cdd6900382ad1ed06df3b6c2ea791 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42260 – drm/v3d: Validate passed in drm syncobj handles in the performance extension
https://notcve.org/view.php?id=CVE-2024-42260
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Validate passed in drm syncobj handles in the performance extension If userspace provides an unknown or invalid handle anywhere in the handle array the rest of the driver will not handle that well. Fix it by checking handle was looked up successfully or otherwise fail the extension by jumping into the existing unwind. (cherry picked from commit a546b7e4d73c23838d7e4d2c92882b3ca902d213) • https://git.kernel.org/stable/c/bae7cb5d68001a8d4ceec5964dda74bb9aab7220 https://git.kernel.org/stable/c/5d4aa25f47cd05e9eeac272906588728588605dd https://git.kernel.org/stable/c/4ecc24a84d7e0254efd150ec23e0b89638386516 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42259 – drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
https://notcve.org/view.php?id=CVE-2024-42259
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) Linux i915 suffers from an out-of-bounds PTE write in vm_fault_gtt() that leads to a PTE use-after-free vulnerability. • https://git.kernel.org/stable/c/c58305af1835095ddc25ee6f548ac05915e66ac5 https://git.kernel.org/stable/c/3e06073d24807f04b4694108a8474decb7b99e60 https://git.kernel.org/stable/c/a256d019eaf044864c7e50312f0a65b323c24f39 https://git.kernel.org/stable/c/50111a8098fb9ade621eeff82228a997d42732ab https://git.kernel.org/stable/c/911f8055f175c82775d0fd8cedcd0b75413f4ba7 https://git.kernel.org/stable/c/e8a68aa842d3f8dd04a46b9d632e5f67fde1da9b https://git.kernel.org/stable/c/4b09513ce93b3dcb590baaaff2ce96f2d098312d https://git.kernel.org/stable/c/ead9289a51ea82eb5b27029fcf4c34b2d •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42258 – mm: huge_memory: use !CONFIG_64BIT to relax huge page alignment on 32 bit machines
https://notcve.org/view.php?id=CVE-2024-42258
In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: use !CONFIG_64BIT to relax huge page alignment on 32 bit machines Yves-Alexis Perez reported commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit") didn't work for x86_32 [1]. It is because x86_32 uses CONFIG_X86_32 instead of CONFIG_32BIT. !CONFIG_64BIT should cover all 32 bit machines. [1] https://lore.kernel.org/linux-mm/CAHbLzkr1LwH3pcTgM+aGQ31ip2bKqiqEQ8=FQB+t2c3dhNKNHA@mail.gmail.com/ • https://git.kernel.org/stable/c/87632bc9ecff5ded93433bc0fca428019bdd1cfe https://git.kernel.org/stable/c/4ef9ad19e17676b9ef071309bc62020e2373705d https://git.kernel.org/stable/c/7432376c913381c5f24d373a87ff629bbde94b47 https://git.kernel.org/stable/c/89f2914dd4b47d2fad3deef0d700f9526d98d11f https://git.kernel.org/stable/c/7e1f4efb8d6140b2ec79bf760c43e1fc186e8dfc https://git.kernel.org/stable/c/d9592025000b3cf26c742f3505da7b83aedc26d5 https://git.kernel.org/stable/c/a5c399fe433a115e9d3693169b5f357f3194af0a https://access.redhat.com/security/cve/CVE-2024-42258 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42257 – ext4: use memtostr_pad() for s_volume_name
https://notcve.org/view.php?id=CVE-2024-42257
In the Linux kernel, the following vulnerability has been resolved: ext4: use memtostr_pad() for s_volume_name As with the other strings in struct ext4_super_block, s_volume_name is not NUL terminated. The other strings were marked in commit 072ebb3bffe6 ("ext4: add nonstring annotations to ext4.h"). Using strscpy() isn't the right replacement for strncpy(); it should use memtostr_pad() instead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: use memtostr_pad() para s_volume_name Al igual que con las otras cadenas en la estructura ext4_super_block, s_volume_name no tiene terminación NUL. Las otras cadenas se marcaron en el commit 072ebb3bffe6 ("ext4: agregue anotaciones que no sean cadenas a ext4.h"). • https://git.kernel.org/stable/c/744a56389f7398f286231e062c2e63f0de01bcc6 https://git.kernel.org/stable/c/4378be89ddb7de88d984b67ecfd6191686c42817 https://git.kernel.org/stable/c/be27cd64461c45a6088a91a04eba5cd44e1767ef •