Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc: Arreglar virt_addr_valid() para Book3E de 64 bits y mpe de 32 bits: En Book3E de 64 bits, el espacio vmalloc comienza en 0x8000000000000000. Debido a la forma en que funciona __pa() tenemos: __pa(0x8000000000000000) == 0, y por lo tanto virt_to_pfn(0x8000000000000000) == 0, y por lo tanto virt_addr_valid(0x8000000000000000) == true Lo cual es incorrecto, virt_addr_valid() debería ser falso para el espacio vmalloc. De hecho, todas las direcciones vmalloc que tengan un alias con un PFN válido devolverán verdadero desde virt_addr_valid(). Esto puede causar errores con usercopy reforzado como lo describe a continuación Kefeng Wang: Al ejecutar ethtool eth0 en Book3E de 64 bits, ocurrió un ERROR: usercopy: ¡Intento de exposición de memoria del kernel detectado desde un objeto SLUB que no está en la página SLUB! (desplazamiento 0, tamaño 1048). ERROR del kernel en mm/usercopy.c:99 ... usercopy_abort+0x64/0xa0 (no confiable) __check_heap_object+0x168/0x190 __check_object_size+0x1a0/0x200 dev_ethtool+0x2494/0x2b20 dev_ioctl+0x5d0/0x770 sock_do_ioctl+0xf0/0x1d0 sock_ioctl+0x3ec/0x5a0 __se_sys_ioctl+0xf0/0x160 system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 El código se muestra a continuación, data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN)); copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) Los datos se asignan mediante vmalloc(), virt_addr_valid(ptr) devolverá verdadero en Book3E de 64 bits, lo que genera el pánico. Como lo hace el commit 4dd7554a6456 ("powerpc/64: Agregar comprobaciones VIRTUAL_BUG_ON para direcciones __va y __pa"), asegúrese de que la dirección virt sea superior a PAGE_OFFSET en virt_addr_valid() para 64 bits, y agregue también una comprobación de límite superior para asegurarse de que la dirección virt esté por debajo de high_memory. Mientras tanto, para 32 bits PAGE_OFFSET es la dirección virtual del inicio de lowmem, high_memory es la dirección virtual baja superior, la comprobación es adecuada para 32 bits, esto solucionará también el problema mencionado en el commit 602946ec2f90 ("powerpc: Set max_mapnr properly"). En 32 bits hay un problema similar con la memoria alta, que se solucionó en el commit 602946ec2f90 ("powerpc: Set max_mapnr properly"), pero ese commit rompe highmem y necesita ser revertido. No podemos arreglar fácilmente __pa(), tenemos código que depende de su comportamiento actual. Así que por ahora agregue comprobaciones adicionales a virt_addr_valid(). Para Book3S de 64 bits las comprobaciones adicionales no son necesarias, la combinación de virt_to_pfn() y pfn_valid() debería producir el resultado correcto, pero son inofensivas. [mpe: Agregar detalles adicionales del registro de cambios]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: tcmu: Fix possible page UAF tcmu_try_get_data_page() busca páginas bajo cmdr_lock, pero no toma el recuento de referencias correctamente y solo devuelve el puntero de página. Cuando tcmu_try_get_data_page() regresa, la página devuelta puede haber sido liberada por tcmu_blocks_release(). Necesitamos get_page() bajo cmdr_lock para evitar tcmu_blocks_release() concurrente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: comprobar si kmalloc_array() puede devolver un valor nulo. Como kmalloc_array() puede devolver un valor nulo, 'event_waiters[i].wait' provocaría una desreferencia de puntero nulo. Por lo tanto, es mejor comprobar el valor de retorno de kmalloc_array() para evitar esta confusión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: se corrige el pánico al reenviar un paquete sin un dev in6 kongweibin informó un pánico del kernel en ip6_forward() cuando la interfaz de entrada no tiene un dev in6 asociado. Se utilizaron los siguientes comandos tc para reproducir este pánico: tc qdisc del dev vxlan100 root tc qdisc add dev vxlan100 root netem corrupt 5%

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memoria: renesas-rpc-if: corrige pérdida de dispositivo de plataforma en ruta de error Asegúrese de liberar el dispositivo de plataforma flash en caso de que el registro falle durante la prueba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usb: aqc111: Arreglar accesos fuera de los límites en RX fixup aqc111_rx_fixup() contiene varios accesos fuera de los límites que pueden ser activados por un dispositivo USB malicioso (o defectuoso), en particular: - La matriz de metadatos (desc_offset..desc_offset+2*pkt_count) puede estar fuera de los límites, causando lecturas OOB y (en sistemas big-endian) cambios de endianness OOB. - Un paquete puede superponerse a la matriz de metadatos, causando que un cambio de endianness OOB posterior corrompa los datos utilizados por un SKB clonado que ya se ha entregado a la pila de red. - Se puede construir un SKB de paquete cuya cola esté mucho más allá de su final, causando que los datos del montón fuera de los límites se consideren parte de los datos del SKB. Se encontró haciendo análisis de variantes. Lo probé con otro controlador (ax88179_178a), ya que no tengo un dispositivo aqc111 para probarlo, pero el código parece muy similar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: corregir la asignación inesperada de páginas en cero con intercambio de zram Dos procesos bajo la clonación CLONE_VM, el proceso del usuario puede corromperse al ver una página en cero inesperadamente. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO ruta SWP_SYNCHRONOUS_IO ruta swap_readpage datos válidos swap_slot_free_notify eliminar entrada zram swap_readpage datos cero (inválidos) pte_lock asigna los *datos cero* al espacio de usuario pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return y el siguiente refault leerá los datos en cero swap_slot_free_notify es falso para el caso de CLONE_VM ya que no aumenta el recuento de referencias de la ranura de intercambio en copy_mm, por lo que no podría ponerse al día si es seguro o no descartar datos del dispositivo de respaldo. En este caso, el único bloqueo en el que podría confiar para sincronizar la liberación de la ranura de intercambio es el bloqueo de la tabla de páginas. Por lo tanto, este parche elimina la función swap_slot_free_notify. Con este parche, la CPU A verá los datos correctos. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault verá los datos mapeados por la CPU B La preocupación del parche aumentaría el consumo de memoria ya que podría mantener la memoria desperdiciada con forma comprimida en zram así como forma sin comprimir en el espacio de direcciones. Sin embargo, la mayoría de los casos de zram no utilizan lectura anticipada y do_swap_page es seguido por swap_free por lo que liberará el formato comprimido de zram rápidamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: Desactivar sysctl_record_panic_msg de forma predeterminada en invitados aislados hv_panic_page puede contener información confidencial del invitado; no la envíe a Hyper-V de forma predeterminada en invitados aislados. Mientras tanto, actualice algunos comentarios en hyperv_{panic,die}_event().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: cancelar la asignación de archivos antes de asignar credenciales. Necesitamos restaurar las credenciales correctamente si fallamos en la asignación de archivos o simplemente hacer la asignación de archivos primero. Hagamos esto último, ya que es más simple; no debería haber ninguna diferencia aquí para la asignación de archivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: null_blk: end timed out poll request Cuando se agota el tiempo de espera de una solicitud de sondeo, se la elimina de la lista de sondeos, pero no se la completa, por lo que se filtra y nunca se la completa. Soluciona el problema finalizándola en el controlador de tiempo de espera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/secretmem: corregir pánico al hacer crecer un memfd_secret Cuando uno intenta hacer crecer un memfd_secret existente con ftruncate, se obtiene un pánico [1]. Por ejemplo, hacer lo siguiente induce de manera confiable el pánico: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20); La razón básica para esto es que, cuando hacemos crecer con ftruncate, llamamos a simple_setattr, y luego a truncate_inode_pages_range, y eventualmente intentamos poner a cero parte de la memoria. El código de truncamiento normal hace esto a través del mapa directo (es decir, llama a page_address() y se la entrega a memset()). Sin embargo, para memfd_secret, específicamente no mapeamos nuestras páginas a través del mapa directo (es decir, llamamos a set_direct_map_invalid_noflush() en cada falla). Por lo tanto, la dirección devuelta por page_address() no es útil, y cuando intentamos usar memset() con ella, nos asustamos. Este parche evita el pánico al implementar un setattr personalizado para memfd_secret, que detecta cambios de tamaño específicamente (establecer el tamaño por primera vez funciona bien, ya que no hay páginas existentes para intentar poner a cero), y los rechaza con EINVAL. Se podría argumentar que se debería admitir el crecimiento, pero creo que eso requerirá un cambio significativamente más largo. Por lo tanto, propongo una solución mínima para el beneficio de los núcleos estables, y luego tal vez extender memfd_secret para admitir el crecimiento en un parche separado. [1]: ERROR: no se puede manejar el error de página para la dirección: ffffa0a889277028 #PF: acceso de escritura del supervisor en modo kernel #PF: error_code(0x0002) - página no presente PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 0 PID: 281 Comm: repro No contaminado 5.17.0-dbg-DEV #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:memset_erms+0x9/0x10 Código: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 RDX: 0000000000000fd8 RSI: 00000000000000000 RDI: ffffa0a889277028 RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ? zero_user_segments+0x82/0x190 truncate_inode_partial_folio+0xd4/0x2a0 truncate_inode_pages_range+0x380/0x830 truncate_setsize+0x63/0x80 simple_setattr+0x37/0x60 notify_change+0x3d8/0x4d0 do_sys_ftruncate+0x162/0x1d0 __x64_sys_ftruncate+0x1c/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae Módulos vinculados en: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet CR2: ffffa0a889277028 [lkp@intel.com: secretmem_iops puede ser estático] Aprobado por: robot de pruebas del núcleo [axelrasmussen@google.com: devolver EINVAL]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ep93xx: clock: Arreglar UAF en ep93xx_clk_register_gate() arch/arm/mach-ep93xx/clock.c:154:2: advertencia: Uso de memoria después de que se libera [clang-analyzer-unix.Malloc] arch/arm/mach-ep93xx/clock.c:151:2: nota: Tomando rama verdadera si (IS_ERR(clk)) ^ arch/arm/mach-ep93xx/clock.c:152:3: nota: Se libera memoria kfree(psc); ^~~~~~~~~~ arch/arm/mach-ep93xx/clock.c:154:2: nota: Uso de memoria después de que se libera return &psc->hw; ^ ~~~~~~~~