CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26603 – x86/fpu: Stop relying on userspace for info to fault in xsave buffer
https://notcve.org/view.php?id=CVE-2024-26603
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak subject / changelog ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/fpu: dejar de depender del espacio de usuario para que la información falle en el búfer xsave Antes de este cambio, el tamaño esperado del búfer de espacio de usuario se tomaba de fx_sw->xstate_size. fx_sw->xstate_size se puede cambiar desde el espacio de usuario, por lo que es posible construir un marco sigreturn donde: * fx_sw->xstate_size es más pequeño que el tamaño requerido por los bits válidos en fx_sw->xfeatures. * el espacio de usuario desasigna partes del búfer fpu de sigrame para que no se pueda acceder a todo el búfer requerido por xrstor. En este caso, xrstor intenta restaurar y accede al área no asignada, lo que genera una falla. Pero falla_in_readable tiene éxito porque buf + fx_sw->xstate_size está dentro del área aún mapeada, por lo que regresa e intenta xrstor nuevamente. • https://git.kernel.org/stable/c/fcb3635f5018e53024c6be3c3213737f469f74ff https://git.kernel.org/stable/c/8bd3eee7720c14b59a206bd05b98d7586bccf99a https://git.kernel.org/stable/c/627339cccdc9166792ecf96bc3c9f711a60ce996 https://git.kernel.org/stable/c/b2479ab426cef7ab79a13005650eff956223ced2 https://git.kernel.org/stable/c/627e28cbb65564e55008315d9e02fbb90478beda https://git.kernel.org/stable/c/d877550eaf2dc9090d782864c96939397a3c6835 https://access.redhat.com/security/cve/CVE-2024-26603 https://bugzilla.redhat.com/show_bug.cgi?id=2265833 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26602 – sched/membarrier: reduce the ability to hammer on sys_membarrier
https://notcve.org/view.php?id=CVE-2024-26602
In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/membarrier: reduce la capacidad de martillar en sys_membarrier. En algunos sistemas, sys_membarrier puede ser muy costoso, provocando ralentizaciones generales en todo. Por lo tanto, bloquee la ruta para serializar los accesos y evitar que se llame a una frecuencia demasiado alta y sature la máquina. • https://git.kernel.org/stable/c/22e4ebb975822833b083533035233d128b30e98f https://git.kernel.org/stable/c/3cd139875e9a7688b3fc715264032620812a5fa3 https://git.kernel.org/stable/c/2441a64070b85c14eecc3728cc87e883f953f265 https://git.kernel.org/stable/c/db896bbe4a9c67cee377e5f6a743350d3ae4acf6 https://git.kernel.org/stable/c/50fb4e17df319bb33be6f14e2a856950c1577dee https://git.kernel.org/stable/c/24ec7504a08a67247fbe798d1de995208a8c128a https://git.kernel.org/stable/c/b6a2a9cbb67545c825ec95f06adb7ff300a2ad71 https://git.kernel.org/stable/c/c5b2063c65d05e79fad8029324581d86c •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26601 – ext4: regenerate buddy after block freeing failed if under fc replay
https://notcve.org/view.php?id=CVE-2024-26601
In the Linux kernel, the following vulnerability has been resolved: ext4: regenerate buddy after block freeing failed if under fc replay This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: regenerar amigo después de que falló la liberación del bloque si se encuentra en reproducción fc. Esto revierte principalmente el commit 6bd97bf273bd ("ext4: eliminar mb_regenerate_buddy() redundante") y reintroduce mb_regenerate_buddy(). • https://git.kernel.org/stable/c/0983142c5f17a62055ec851372273c3bc77e4788 https://git.kernel.org/stable/c/6bd97bf273bdb4944904e57480f6545bca48ad77 https://git.kernel.org/stable/c/94ebf71bddbcd4ab1ce43ae32c6cb66396d2d51a https://git.kernel.org/stable/c/c1317822e2de80e78f137d3a2d99febab1b80326 https://git.kernel.org/stable/c/78327acd4cdc4a1601af718b781eece577b6b7d4 https://git.kernel.org/stable/c/ea42d6cffb0dd27a417f410b9d0011e9859328cb https://git.kernel.org/stable/c/6b0d48647935e4b8c7b75d1eccb9043fcd4ee581 https://git.kernel.org/stable/c/c9b528c35795b711331ed36dc3dbee90d • CWE-118: Incorrect Access of Indexable Resource ('Range Error') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26600 – phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
https://notcve.org/view.php?id=CVE-2024-26600
In the Linux kernel, the following vulnerability has been resolved: phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example: configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88 __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 Let's fix the issue by checking for send_srp() and set_vbus() before calling them. For USB peripheral only cases these both could be NULL. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: ti: phy-omap-usb2: corrige la desreferencia del puntero NULL para SRP. • https://git.kernel.org/stable/c/657b306a7bdfca4ae1514b533a0e7c3c6d26dbc6 https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5 https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3 https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462 https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4 https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4 https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f64 • CWE-476: NULL Pointer Dereference •
CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26598 – KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
https://notcve.org/view.php?id=CVE-2024-26598
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: vgic-its: Evite posibles UAF en la caché de traducción LPI. Existe un escenario potencial de UAF en el caso de que un caché de traducción LPI se acelere con una operación que invalide la caché, como un comando DISCARD ITS. La raíz del problema es que vgic_its_check_cache() no eleva el refcount en vgic_irq antes de eliminar el bloqueo que serializa los cambios de refcount. • https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88 https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703 https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4 https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6 https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1 https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80 https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-416: Use After Free •