Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: desmarcar inodo en uso en ruta de error Desmarcar inodo en uso si se encuentra un error. Si la fuga de la bandera en uso ocurre en cachefiles_open_file(), Cachefiles mostrará el mensaje "Inodo ya en uso" cuando más tarde se busque otra cookie con la misma clave de índice. Si la fuga de la bandera en uso ocurre en cachefiles_create_tmpfile(), aunque no se active la advertencia "Inodo ya en uso", solucione la fuga de todos modos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: Arreglar la clase de seguimiento svc_deferred_event Arreglar un fallo de desreferencia NULL que ocurre cuando se aplaza un svc_rqst mientras el subsistema de seguimiento sunrpc está habilitado. svc_revisit() establece dr->xprt en NULL, por lo que no se puede confiar en él en el punto de seguimiento para proporcionar la dirección del control remoto. Desafortunadamente, no podemos revertir el trozo "svc_deferred_class" en el commit ece200ddd54b ("sunrpc: Guardar la dirección de presentación remota en svc_xprt para eventos de seguimiento") porque ahora hay una comprobación específica de especificadores de formato de evento para desreferencias inseguras. La advertencia que emite la comprobación es: el evento svc_defer_recv tiene una desreferencia insegura del argumento 1 Un especificador de formato "%pISpc" con un "struct sockaddr *" está marcado por esta comprobación. En su lugar, adopte el enfoque de fuerza bruta utilizado por el punto de seguimiento svcrdma_qp_error. Convierta el campo dr::addr en una dirección de presentación en el brazo TP_fast_assign() del evento de seguimiento y almacénelo como una cadena. Esta corrección se puede implementar en kernels estables. Mientras tanto, el commit c6ced22997ad ("seguimiento: Actualizar la comprobación de impresión fmt para manejar la nueva macro __get_sockaddr()") ahora está en v5.18, por lo que esta corrección complicada se puede reemplazar con __sockaddr() y similares correctamente durante la ventana de fusión de v5.19.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: veth: Asegurarse de que el encabezado eth esté en la parte lineal de skb Después de alimentar un paquete desencapsulado a un dispositivo veth con act_mirred, skb_headlen() puede ser 0. Pero veth_xmit() llama a __dev_forward_skb(), que espera al menos ETH_HLEN bytes de datos lineales (como __dev_forward_skb2() llama a eth_type_trans(), que extrae ETH_HLEN bytes incondicionalmente). Utilice pskb_may_pull() para asegurarse de que veth_xmit() respete esta restricción. ¡ERROR del kernel en include/linux/skbuff.h:2328! RIP: 0010:eth_type_trans+0xcf/0x140 Rastreo de llamadas: __dev_forward_skb2+0xe3/0x160 veth_xmit+0x6e/0x250 [veth] dev_hard_start_xmit+0xc7/0x200 __dev_queue_xmit+0x47f/0x520 ? skb_ensure_writable+0x85/0xa0 ? skb_mpls_pop+0x98/0x1c0 tcf_mirred_act+0x442/0x47e [act_mirred] tcf_action_exec+0x86/0x140 fl_classify+0x1d8/0x1e0 [cls_flower] ? skb_copy_bits+0x11a/0x220 __tcf_classify+0x58/0x110 tcf_classify_ingress+0x6b/0x140 __netif_receive_skb_core.constprop.0+0x47d/0xfd0 ? __iommu_dma_unmap_swiotlb+0x44/0x90 __netif_receive_skb_one_core+0x3d/0xa0 netif_receive_skb+0x116/0x170 be_process_rx+0x22f/0x330 [be2net] be_poll+0x13c/0x370 [be2net] __napi_poll+0x2a/0x170 net_rx_action+0x22f/0x2f0 __do_softirq+0xca/0x2a8 __irq_exit_rcu+0xc1/0xe0 common_interrupt+0x83/0xa0

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: ice: arfs: corregir use-after-free al liberar @rx_cpu_rmap Los bots de prueba de CI activaron el siguiente splat: [ 718.203054] ERROR: KASAN: use-after-free en free_irq_cpu_rmap+0x53/0x80 [ 718.206349] Lectura de tamaño 4 en la dirección ffff8881bd127e00 por la tarea sh/20834 [ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: cargado Tainted: GSW IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1 [ 718.219695] Hardware nombre: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020 [ 718.223418] Seguimiento de llamadas: [ 718.227139] [ 718.230783] dump_stack_lvl+0x33/0x42 [ 718.234431] print_address_description.constprop.9+0x21/0x170 [ 718.238177] ? free_irq_cpu_rmap+0x53/0x80 [ 718.241885] ? informe_kasan.cold.18+0x7f/0x11b [ 718.249197] ? free_irq_cpu_rmap+0x53/0x80 [ 718.252852] free_irq_cpu_rmap+0x53/0x80 [ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [hielo] [ 718.260174] ice_remove_arfs+0x5f/0x70 [hielo] [ 718.263810] ice_rebuild_arfs+0x3b/0x70 [hielo] [ 718.267419] ice_rebuild+0x39c/0xb60 [hielo] [ 718.270974] ? preempt_count_sub+0x14/0xc0 [ 718.284984] ? delay_tsc+0x8f/0xb0 [ 718.288463] ice_do_reset+0x92/0xf0 [ice] [ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice] [ 718.295561] pci_reset_function+0x53/0x80 <...> [ 718.393035] Asignado por la tarea 690: [ 718.433497] Liberado por la tarea 20834: [ 718.495688] Última creación de trabajo potencialmente relacionada: [ 718.568966] La dirección con errores pertenece al objeto en ffff8881bd127e00 que pertenece a la caché kmalloc-96 de tamaño 96 [ 718.574085] La dirección con errores se encuentra a 0 bytes dentro de la región de 96 bytes [ffff8881bd127e00, ffff8881bd127e60) [ 718.579265] La dirección con errores pertenece a la página: [ 718.598905] Estado de la memoria alrededor de la dirección con errores: [ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc [ 718.607794] >ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.610811] ^ [ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc Esto se debe a que free_irq_cpu_rmap() siempre se llama *después* de (devm_)free_irq() y, por lo tanto, intenta funcionar. con descripciones IRQ ya liberadas. Por ejemplo, al reiniciar el dispositivo, el controlador libera el rmap justo antes de asignar uno nuevo (el símbolo de arriba). Haga que la creación y liberación de rmap sean simétricas con las llamadas {request,free}_irq(), es decir, hágalo en ifup/ifdown en lugar de en la prueba/eliminación/reanudación del dispositivo. Estas operaciones se pueden realizar independientemente de la configuración aRFS del dispositivo real. Además, asegúrese de que ice_vsi_free_irq() borre los notificadores de afinidad IRQ solo cuando aRFS esté deshabilitado; de lo contrario, el rmap de la CPU establece y borra los suyos propios y no se deben tocar manualmente.

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: 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: 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: 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: 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().