CVSS: 5.5EPSS: 0%CPEs: 18EXPL: 0CVE-2024-26720 – mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
https://notcve.org/view.php?id=CVE-2024-26720
In the Linux kernel, the following vulnerability has been resolved: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again (struct dirty_throttle_control *)->thresh is an unsigned long, but is passed as the u32 divisor argument to div_u64(). On architectures where unsigned long is 64 bytes, the argument will be implicitly truncated. Use div64_u64() instead of div_u64() so that the value used in the "is this a safe division" check is the same as the divisor. Also, remove redundant cast of the numerator to u64, as that should happen implicitly. This would be difficult to exploit in memcg domain, given the ratio-based arithmetic domain_drity_limits() uses, but is much easier in global writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/writeback: corrige la posible división por cero en wb_dirty_limits(), nuevamente (struct dirty_throttle_control *)->thresh es un largo sin firmar, pero se pasa como argumento del divisor u32 a div_u64(). En arquitecturas donde la longitud sin firmar es de 64 bytes, el argumento se truncará implícitamente. Utilice div64_u64() en lugar de div_u64() para que el valor utilizado en la comprobación "¿Es esta una división segura" sea el mismo que el divisor? Además, elimine la conversión redundante del numerador a u64, ya que eso debería suceder implícitamente. • https://git.kernel.org/stable/c/f6789593d5cea42a4ecb1cbeab6a23ade5ebbba7 https://git.kernel.org/stable/c/c5fec566bef6a027e75c84c35ec970482eb88cea https://git.kernel.org/stable/c/c05d1fe6c19f4df2f0b8cba151a8f0c53b87d878 https://git.kernel.org/stable/c/3f7d325fbbe12e5ade71a1f90759c06ed2d27e3c https://git.kernel.org/stable/c/c593d26fb5d577ef31b6e49a31e08ae3ebc1bc1e https://git.kernel.org/stable/c/253f9ea7e8e53a5176bd80ceb174907b10724c1a https://git.kernel.org/stable/c/1f12e4b3284d6c863f272eb2de0d4248ed211cf4 https://git.kernel.org/stable/c/23a28f5f3f6ca1e4184bd0e9631cd0944 • CWE-369: Divide By Zero •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26719 – nouveau: offload fence uevents work to workqueue
https://notcve.org/view.php?id=CVE-2024-26719
In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nuevo: descargar valla uevents work to workqueue Esto debería romper el punto muerto entre el bloqueo fctx y el bloqueo irq. Esto descarga el procesamiento del trabajo del irq a una cola de trabajo. • https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906 https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9 https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26706 – parisc: Fix random data corruption from exception handler
https://notcve.org/view.php?id=CVE-2024-26706
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not convert to an integer. This patch takes another, better and more flexible approach: We extend the __ex_table (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction "or %r0,%r0,%reg", where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the __ex_table entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register. Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT config option any longer. • https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592 https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2 https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003 https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26700 – drm/amd/display: Fix MST Null Ptr for RV
https://notcve.org/view.php?id=CVE-2024-26700
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix MST Null Ptr for RV The change try to fix below error specific to RV platform: BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? • https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238 https://git.kernel.org/stable/c/7407c61f43b66e90ad127d0cdd13cbc9d87141a5 https://git.kernel.org/stable/c/5cd7185d2db76c42a9b7e69adad9591d9fca093f https://git.kernel.org/stable/c/e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26699 – drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr
https://notcve.org/view.php?id=CVE-2024-26699
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr [Why] There is a potential memory access violation while iterating through array of dcn35 clks. [How] Limit iteration per array size. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige el índice de matriz fuera de los límites en dcn35_clkmgr [Por qué] Existe una posible infracción de acceso a la memoria al iterar a través de una matriz de clks dcn35. [Cómo] Limitar la iteración por tamaño de matriz. • https://git.kernel.org/stable/c/ca400d8e0c1c9d79c08dfb6b7f966e26c8cae7fb https://git.kernel.org/stable/c/46806e59a87790760870d216f54951a5b4d545bc •