CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26715 – usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend
https://notcve.org/view.php?id=CVE-2024-26715
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: gadget: corrige la desreferencia del puntero NULL en dwc3_gadget_suspend En el escenario actual, si el Plug-out y el Plug-In se ejecutan continuamente, podría haber una posibilidad al verificar dwc->gadget_driver en dwc3_gadget_suspend, puede ocurrir una desreferencia del puntero NULL. Pila de llamadas: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 básicamente borra la variable y CPU2 verifica la variable. Considere que CPU1 se está ejecutando y justo antes de que se borre gadget_driver y en paralelo CPU2 ejecuta dwc3_gadget_suspend donde encuentra dwc->gadget_driver que no es NULL y reanuda la ejecución y luego CPU1 completa la ejecución. • https://git.kernel.org/stable/c/9772b47a4c2916d645c551228b6085ea24acbe5d https://git.kernel.org/stable/c/8cca5c85393a7a490d4d7942c24d73d29cc77b3e https://git.kernel.org/stable/c/df2ca3271569367352835f981618e284fdc4ca94 https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7 https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751 https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182 https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8 •
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: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26704 – ext4: fix double-free of blocks due to wrong extents moved_len
https://notcve.org/view.php?id=CVE-2024-26704
In the Linux kernel, the following vulnerability has been resolved: ext4: fix double-free of blocks due to wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update move_len after each extent move to avoid the issue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige la doble liberación de bloques debido a extensiones incorrectas. moving_len En ext4_move_extents(), move_len solo se actualiza cuando todos los movimientos se ejecutan exitosamente y solo descarta las preasignaciones de orig_inode y donante_inode cuando se mueve_len no es cero. Cuando el bucle no sale después de mover con éxito algunas extensiones, moving_len no se actualiza y permanece en 0, por lo que no descarta las asignaciones previas. • https://git.kernel.org/stable/c/fcf6b1b729bcd23f2b49a84fb33ffbb44712ee6a https://git.kernel.org/stable/c/b4fbb89d722cbb16beaaea234b7230faaaf68c71 https://git.kernel.org/stable/c/afbcad9ae7d6d11608399188f03a837451b6b3a1 https://git.kernel.org/stable/c/d033a555d9a1cf53dbf3301af7199cc4a4c8f537 https://git.kernel.org/stable/c/afba9d11320dad5ce222ac8964caf64b7b4bedb1 https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1 https://git.kernel.org/stable/c/2883940b19c38d5884c8626483811acf4d7e148f https://git.kernel.org/stable/c/559ddacb90da1d8786dd8ec4fd76bbfa4 • CWE-415: Double Free •
CVSS: 4.3EPSS: 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 https://access.redhat.com/security/cve/CVE-2024-26700 https://bugzilla.redhat.com/show_bug.cgi?id=2273113 • CWE-476: NULL Pointer Dereference •
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 •