Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: esp: corrige el mal manejo de las páginas desde page_pool Cuando el skb se reorganiza durante esp_output (!esp->inline), se supone que las páginas provenientes de los fragmentos del skb original son devuelto al sistema a través de put_page. Pero si las páginas del fragmento skb se originan en un page_pool, llamar a put_page en ellas desencadenará una fuga de page_pool que eventualmente resultará en un bloqueo. Esta fuga se puede observar fácilmente cuando se usa CONFIG_DEBUG_VM y se realiza el reenvío ipsec + gre (no descargado): ERROR: Estado de página incorrecto en el proceso ksoftirqd/16 pfn:1451b6 página:00000000de2b8d32 refcount:0 mapcount:0 mapeo:0000000000000000 índice:0x1451b6000 pfn: 0x1451b6 banderas: 0x200000000000000(nodo=0|zona=2) tipo de página: 0xffffffff() sin formato: 0200000000000000 muerto000000000040 ffff88810d23c000 0000000000000000 sin formato: 0001451b6000 0000000000000001 00000000ffffffff 0000000000000000 página volcada porque: fuga de page_pool Módulos vinculados en: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [última descarga: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 No contaminado 6 .8.0-rc4+ #22 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validar_xmit_xfrm+0x313/0x370 ? validar_xmit_skb+0x1d/0x330 validar_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x1ca/0x580 ip_sublist_rcv_finish+0x32/0x40 ip_sublist_rcv+0x1b2/0x1f0 ? ip_rcv_finish_core.constprop.0+0x460/0x460 ip_list_rcv+0x103/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x1b3/0x2c0 napi_gro_receive+0xc8/0x200 encuesta+0x52/0x90 __napi_poll+0x25/0x1a0 net_rx_action+0x28e/0x300 __do_softirq+0xc3/0x276 ? sort_range+0x20/0x20 run_ksoftirqd+0x1e/0x30 smpboot_thread_fn+0xa6/0x130 kthread+0xcd/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x31/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 La solución sugerida es introducir un nuevo contenedor (skb_page_unref) que cubra también el recuento de páginas para las páginas page_pool.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/zcrypt: corrige el recuento de referencias en los objetos de la tarjeta zcrypt. Las pruebas con tarjetas crypto de conexión en caliente en invitados KVM con compilación del kernel de depuración revelaron un use after free el campo de carga de la estructura zcrypt_card . El motivo fue un manejo de referencia incorrecto del objeto de la tarjeta zcrypt que podría provocar la liberación del objeto de la tarjeta zcrypt mientras aún estaba en uso. Este es un ejemplo del mensaje de losa: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. Primer byte 0x68 en lugar de 0x6b kernel: Asignado en zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/ 0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: Actually_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_ adjuntar+0x114/0x198 kernel: bus_probe_device+ Kernel 0xb4/0xc8: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: Process_one_work+0x26e/0x620 kernel: Kernel x21c/0x440: liberado en zcrypt_card_put +0x54/0x80 [zcrypt] edad=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device +0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: Núcleo 26e/0x620: trabajador_thread+ Kernel 0x21c/0x440: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objetos=20 usados=18 fp=0x00000000885a7c88 3ffff00000000a00(conjunto de trabajo|losa|nodo=0|zona =1|lastcpupid=0x1ffff) kernel: Objeto 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Objeto 00000000885a74 b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Objeto 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkk kkkkkkkk kernel: Objeto 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkk kernel: Objeto 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkk kernel: Objeto 000000 00885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel : Objeto 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd -udevd Not tainted 6.8.0-HF #2 kernel: Nombre del hardware: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report +0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] +0x1ee/0x3e0 núcleo: [<00000000c99d94ec> ] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0 ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [< 00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wireguard: netlink: verifique si hay pares pendientes a través de is_dead en lugar de una lista vacía. Si todos los pares se eliminan a través de wg_peer_remove_all(), en lugar de configurar peer_list como vacío, el par se agrega a una lista temporal. lista con un encabezado en la pila de wg_peer_remove_all(). Si se reanuda un volcado de netlink y el par seleccionado es uno que se eliminó mediante wg_peer_remove_all(), iterará desde ese par y luego intentará volcar los pares liberados. Para solucionar este problema, marque peer->is_dead, que se creó explícitamente para este propósito. También suba la aserción de bloqueo de dispositivo_update_lock, ya que la lectura is_dead depende de eso. Se puede reproducir mediante un pequeño script como: echo "Configuración de configuración..." ip link add dev wg0 tipo wireguard wg setconf wg0 /big-config (mientras sea verdadero; haga echo "Mostrando configuración..." wg showconf wg0 > / dev/null done) & sleep 4 wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n") Resultando en: ERROR: KASAN: slab-use-after-free en __lock_acquire+0x182a/0x1b20 Lectura de tamaño 8 en la dirección ffff88811956ec70 mediante la tarea wg/59 CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5 Seguimiento de llamadas: dump_stack_lvl+0x47/0x70 print_address_description.constprop.0+0x2c /0x380 print_report+0xab/0x250 kasan_report+0xba/0xf0 __lock_acquire+0x182a/0x1b20 lock_acquire+0x191/0x4b0 down_read+0x80/0x440 get_peer+0x140/0xcb0 wg_get_device_dump+0x471/0x1130

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el error al detectar daños en DAT en btree y asignaciones directas Serie de parches "nilfs2: corrige el error del kernel en submit_bh_wbc()". Esto resuelve un ERROR del kernel informado por syzbot. Dado que hay dos fallas involucradas, hice un parche para cada uno por separado. El primer parche por sí solo resuelve el error reportado por syzbot, pero creo que ambas correcciones deberían enviarse a estable, así que las etiqueté como tales. Este parche (de 2): Syzbot ha informado de un error en el kernel en submit_bh_wbc() al escribir datos de archivos en un sistema de archivos nilfs2 cuyos metadatos están dañados. Hay dos errores involucrados en este tema. El primer defecto es que cuando nilfs_get_block() localiza un bloque de datos usando btree o mapeo directo, si la rutina de traducción de direcciones de disco nilfs_dat_translate() falla con el código interno -ENOENT debido a la corrupción de los metadatos DAT, se puede devolver a nilfs_get_block(). Esto hace que nilfs_get_block() identifique erróneamente un bloque existente como inexistente, lo que provoca que tanto la búsqueda como la inserción del bloque de datos fallen de manera inconsistente. El segundo defecto es que nilfs_get_block() devuelve un estado exitoso en este estado inconsistente. Esto hace que la persona que llama __block_write_begin_int() u otros soliciten una lectura aunque el búfer no esté asignado, lo que resulta en una verificación BUG_ON para el indicador BH_Mapped en submit_bh_wbc() que falla. Esto soluciona el primer problema cambiando el valor de retorno al código -EINVAL cuando falla una conversión usando DAT con el código -ENOENT, evitando la condición conflictiva que conduce al error del kernel descrito anteriormente. Aquí, el código -EINVAL indica que se detectó corrupción de metadatos durante la búsqueda del bloque, lo que se manejará adecuadamente como un error del sistema de archivos y se convertirá a -EIO al pasar a través de la capa bmap nilfs2.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: previene el error del kernel en submit_bh_wbc(). Se corrige un error por el cual nilfs_get_block() devuelve un estado exitoso cuando la búsqueda y la inserción del bloque especificado fallan de manera inconsistente. Si este comportamiento inconsistente no se debe a un error solucionado previamente, entonces se está produciendo una ejecución inesperada, por lo que se devuelve un error temporal -EAGAIN. Esto evita que llamadores como __block_write_begin_int() soliciten una lectura en un búfer que no está asignado, lo que provocaría que falle la verificación BUG_ON del indicador BH_Mapped en submit_bh_wbc().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige posibles límites cuando el desplazamiento del búfer no es válido. Encontré posibles límites cuando los campos de desplazamiento del búfer de algunas solicitudes no son válidos. Este parche establece el valor mínimo del campo de compensación del búfer en ->Desplazamiento del búfer para validar la longitud del búfer.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige slab-out-of-bounds en smb_strndup_from_utf16() Si ->NameOffset de smb2_create_req es menor que el desplazamiento del búfer de smb2_create_req, puede ocurrir una lectura de slab-out-of-bounds de smb2_open. Este parche establece el valor mínimo del desplazamiento del nombre en el desplazamiento del búfer para validar la longitud del nombre de smb2_create_req().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: iaa - Corrige el caso nr_cpus < nr_iaa Si nr_cpus < nr_iaa, el cpus_per_iaa calculado será 0, lo que provoca una división por 0 en rebalance_wq_table(). Asegúrese de que cpus_per_iaa sea 1 en ese caso, y también en el caso de nr_iaa == 0, aunque cpus_per_iaa nunca se use si nr_iaa == 0, para paranoia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes/x86: use copy_from_kernel_nofault() para leer desde una dirección no segura Lea desde una dirección no segura con copy_from_kernel_nofault() en arch_adjust_kprobe_addr() porque esta función se usa antes de verificar que la dirección esté en texto O no. El bot Syzcaller encontró un error e informó el caso si el usuario especifica un área de datos inaccesible, arch_adjust_kprobe_addr() provocará un pánico en el kernel. [ mingo: Aclaró el comentario. ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ARM: 9359/1: descarga: verifique si la publicación está reservada para direcciones sin asignación. Desde el commit a4d5613c4dc6 ("arm: extienda pfn_valid para tener en cuenta la alineación del mapa de memoria liberada") cambia la semántica de pfn_valid() para verificar la presencia del mapa de memoria para un PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] el diseño de uio es? 0xc0900000, 0x100000 el seguimiento del fallo es como: No se puede manejar la solicitud de paginación del kernel en la dirección virtual bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Contaminado: GO 5.10.0 #1 Nombre del hardware: La PC del sistema basado en DT genérico está en b15_flush_kern_dcache_area+0x24/0x3c LR está en __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) de (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) de (set_pte_at+0x2 8/0x54) (set_pte_at) desde (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) desde (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) desde (__mmap_region+0x264/0x5f4) (__mmap_region) desde (__do_mmap_mm+0x3ec/0x440) milímetros) de (do_mmap+0x50/0x58) (do_mmap) de (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) de (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) de (ret_fast_syscall+0x0/0x5c) Código: e0801001 423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Pánico del kernel - no se sincroniza: excepción fatal. Así que verifique si PG_reserved estaba configurado para resolver este problema. [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: agregue una verificación dc_state NULL en dc_state_release [Cómo] Verifique si el estado es NULL antes de liberarlo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu/pm: corrige la desreferencia del puntero NULL cuando se obtiene el límite de energía. Debido a que la inicialización de powerplay_table se omite en el caso sriov, verificamos y configuramos el valor OD inferior y superior predeterminado si powerplay_table es NULL.