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: -EPSS: 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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42253 – gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
https://notcve.org/view.php?id=CVE-2024-42253
In the Linux kernel, the following vulnerability has been resolved: gpio: pca953x: fix pca953x_irq_bus_sync_unlock race Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races. The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs(). The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system. * Normal case 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 * Race case 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: pca953x: corrige la ejecución pca953x_irq_bus_sync_unlock Asegúrese de que se mantenga `i2c_lock' al configurar el bloqueo de interrupción y la máscara en pca953x_irq_bus_sync_unlock() para evitar ejecuciones. El otro sitio de llamada (que no es de sonda) pca953x_gpio_set_multiple() garantiza que el bloqueo se mantenga antes de llamar a pca953x_write_regs(). El problema ocurrió cuando una solicitud corrió contra irq_bus_sync_unlock() aproximadamente una vez por cada mil reinicios en un sistema basado en i.MX8MP. * Caso normal 0-0022: escribir registro AI|3a {03,02,00,00,01} Enclavamiento de entrada P0 0-0022: escribir registro AI|49 {fc,fd,ff,ff,fe} Máscara de interrupción P0 0 -0022: escribir registro AI|08 {ff,00,00,00,00} Salida P3 0-0022: escribir registro AI|12 {fc,00,00,00,00} Configuración P3 * Caso de ejecución 0-0022: escribir registro AI|08 {ff,00,00,00,00} Salida P3 0-0022: escribir registro AI|08 {03,02,00,00,01} *** Registro incorrecto *** 0-0022: escribir registro AI|12 {fc,00,00,00,00} Config P3 0-0022: escribir registro AI|49 {fc,fd,ff,ff,fe} Máscara de interrupción P0 • https://git.kernel.org/stable/c/58a5c93bd1a6e949267400080f07e57ffe05ec34 https://git.kernel.org/stable/c/e2ecdddca80dd845df42376e4b0197fe97018ba2 https://git.kernel.org/stable/c/de7cffa53149c7b48bd1bb29b02390c9f05b7f41 https://git.kernel.org/stable/c/bfc6444b57dc7186b6acc964705d7516cbaf3904 •