CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26710 – powerpc/kasan: Limit KASAN thread size increase to 32KB
https://notcve.org/view.php?id=CVE-2024-26710
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Limit KASAN thread size increase to 32KB KASAN is seen to increase stack usage, to the point that it was reported to lead to stack overflow on some 32-bit machines (see link). To avoid overflows the stack size was doubled for KASAN builds in commit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase with KASAN"). However with a 32KB stack size to begin with, the doubling leads to a 64KB stack, which causes build errors: arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff) Although the asm could be reworked, in practice a 32KB stack seems sufficient even for KASAN builds - the additional usage seems to be in the 2-3KB range for a 64-bit KASAN build. So only increase the stack for KASAN if the stack size is < 32KB. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/kasan: limitar el aumento del tamaño del subproceso KASAN a 32 KB. Se considera que KASAN aumenta el uso de la pila, hasta el punto de que se informó que provoca un desbordamiento de la pila en algunas máquinas de 32 bits ( ver enlace). Para evitar desbordamientos, el tamaño de la pila se duplicó para las compilaciones de KASAN en el commit 3e8635fb2e07 ("powerpc/kasan: Forzar el aumento del tamaño del subproceso con KASAN"). Sin embargo, con un tamaño de pila de 32 KB para empezar, la duplicación conduce a una pila de 64 KB, lo que provoca errores de compilación: arch/powerpc/kernel/switch.S:249: Error: operando fuera de rango (0x000000000000fe50 no está entre 0xffffffffffff8000 y 0x00000000000007fff) Aunque el conjunto podría modificarse, en la práctica una pila de 32 KB parece suficiente incluso para compilaciones KASAN; el uso adicional parece estar en el rango de 2 a 3 KB para una compilación KASAN de 64 bits. • https://git.kernel.org/stable/c/9ccf64e763aca088b0d25c1274af42b1a6a45135 https://git.kernel.org/stable/c/b38014874530d3776de75679315e8c1fe04aa89b https://git.kernel.org/stable/c/58f396513cb1fa4ef91838c78698d458100cc27c https://git.kernel.org/stable/c/f9a4c401bf4c5af3437ad221c0a5880a518068d4 https://git.kernel.org/stable/c/4297217bcf1f0948a19c2bacc6b68d92e7778ad9 https://git.kernel.org/stable/c/4cc31fa07445879a13750cb061bb8c2654975fcb https://git.kernel.org/stable/c/b29b16bd836a838b7690f80e37f8376414c74cbe https://git.kernel.org/stable/c/f1acb109505d983779bbb7e20a1ee6244 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26707 – net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
https://notcve.org/view.php?id=CVE-2024-26707
In the Linux kernel, the following vulnerability has been resolved: net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame() Syzkaller reported [1] hitting a warning after failing to allocate resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will not help much in this case, it might be prudent to switch to netdev_warn_once(). At the very least it will suppress syzkaller reports such as [1]. Just in case, use netdev_warn_once() in send_prp_supervision_frame() for similar reasons. [1] HSR: Could not send supervision frame WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 ... Call Trace: <IRQ> hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ... This issue is also found in older kernels (at least up to 5.10). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hsr: eliminar WARN_ONCE() en send_hsr_supervision_frame() Syzkaller informó [1] que apareció una advertencia después de no poder asignar recursos para skb en hsr_init_skb(). Dado que una llamada WARN_ONCE() no ayudará mucho en este caso, podría ser prudente cambiar a netdev_warn_once(). • https://git.kernel.org/stable/c/121c33b07b3127f501b366bc23d2a590e2f2b8ef https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb https://git.kernel.org/stable/c/de769423b2f053182a41317c4db5a927e90622a0 https://git.kernel.org/stable/c/56440799fc4621c279df16176f83a995d056023a https://git.kernel.org/stable/c/923dea2a7ea9e1ef5ac4031fba461c1cc92e32b8 https://git.kernel.org/stable/c/547545e50c913861219947ce490c68a1776b9b51 https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e https://lists.debian.org/debian-lts-announce/2024/06/ •
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: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26702 – iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC
https://notcve.org/view.php?id=CVE-2024-26702
In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC Recently, we encounter kernel crash in function rm3100_common_probe caused by out of bound access of array rm3100_samp_rates (because of underlying hardware failures). Add boundary check to prevent out of bound access. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: magnetómetro: rm3100: agregue verificación de los límites para el valor leído de RM3100_REG_TMRC Recientemente, encontramos una falla del kernel en la función rm3100_common_probe causada por el acceso fuera de los límites de la matriz rm3100_samp_rates (debido al hardware subyacente fallas). Agregue verificación de los límites para evitar el acceso fuera de los límites. • https://git.kernel.org/stable/c/121354b2eceb2669ebdffa76b105ad6c03413966 https://git.kernel.org/stable/c/7200170e88e3ec54d9e9c63f07514c3cead11481 https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56 https://git.kernel.org/stable/c/8d5838a473e8e6d812257c69745f5920e4924a60 https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513 https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01 https://git.kernel.org/stable/c/57d05dbbcd0b3dc0c252103b43012eef5d6430d1 https://git.kernel.org/stable/c/792595bab4925aa06532a14dd256db523 •