Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Marcar argumentos raw_tp con PTR_MAYBE_NULL Los argumentos para un tracepoint sin procesar se etiquetan como confiables, lo que conlleva la semántica de que el puntero no será NULL. Sin embargo, en ciertos casos, un argumento de tracepoint sin procesar puede terminar siendo NULL. Hay más contexto disponible sobre este problema en [0]. Por lo tanto, existe una discrepancia entre la realidad, que los argumentos raw_tp pueden ser NULL, y el conocimiento del verificador, de que nunca son NULL, lo que hace que se eliminen las comprobaciones NULL explícitas y los accesos a dichos punteros potencialmente bloqueen el kernel. Para solucionar esto, marque los argumentos raw_tp como PTR_MAYBE_NULL y luego aplique un caso especial a la desreferencia y la aritmética de punteros para permitirlo, y permita pasarlos a ayudantes/kfuncs; estas excepciones se realizan solo para programas raw_tp. Asegúrese de no hacer esto cuando ref_obj_id > 0, ya que en ese caso se trata de un objeto adquirido y no necesita dicho ajuste. La razón por la que hacemos la lógica mask_raw_tp_trusted_reg es porque otros volverán a verificar en algunos lugares si el registro es un trusted_reg y luego considerarán nuestro registro como no confiable al detectar la presencia del indicador PTR_MAYBE_NULL. Para permitir una desreferencia segura, habilitamos el marcado PROBE_MEM cuando vemos cargas en punteros confiables con PTR_MAYBE_NULL. Si bien los argumentos raw_tp confiables también se pueden pasar a los ayudantes o kfuncs donde tal suposición rota puede causar problemas, un futuro conjunto de parches abordará su caso por separado, ya que PTR_TO_BTF_ID (sin PTR_TRUSTED) ya se puede pasar a los ayudantes y causa problemas similares. Por lo tanto, se dejan solos por ahora. Es posible que estas verificaciones también permitan pasar argumentos que no sean raw_tp que sean PTR_TO_BTF_ID confiables con marcado nulo. En tal caso, permitir la desreferencia cuando el puntero es NULL expande el comportamiento permitido, por lo que no se producirá una regresión de los programas existentes, y el caso de pasarlos a los ayudantes es el mismo que el anterior y se tratará más adelante. También actualice el caso de falla en la autoprueba tp_btf_nullable para capturar el nuevo comportamiento, ya que el verificador ya no provocará un error cuando desreferencia directamente un argumento de punto de seguimiento sin formato marcado como __nullable. [0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/pci: Arreglar posible doble eliminación de ranura hotplug En el commit 6ee600bfbe0f ("s390/pci: eliminar ranura hotplug al liberar el dispositivo"), zpci_exit_slot() se movió de zpci_device_reserved() a zpci_release_device() con la intención de mantener la ranura hotplug hasta que el dispositivo sea realmente eliminado. Ahora, zpci_release_device() solo se llama una vez que se eliminan todas las referencias. Dado que el subsistema zPCI solo elimina su referencia una vez que el dispositivo está en el estado reservado, se deduce que zpci_release_device() solo debe tratar con dispositivos en el estado reservado. A pesar de eso, contiene código para desmantelar tanto el estado configurado como el de espera. Para el caso de espera, esto ya incluye la eliminación de la ranura hotplug, por lo que causaría una doble eliminación si un dispositivo alguna vez se eliminara en estado configurado o de espera. En lugar de provocar una posible doble eliminación en un caso que nunca debería ocurrir, use WARN_ON() explícitamente si se libera un dispositivo en estado no reservado y elimine los casos de código inactivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: wl128x: Se corrige la violación de atomicidad en fmc_send_cmd() La violación de atomicidad ocurre cuando la función fmc_send_cmd() se ejecuta simultáneamente con la modificación del valor fmdev->resp_skb. Considere un escenario donde, después de pasar la verificación de validez dentro de la función, a una variable fmdev->resp_skb no nula se le asigna un valor nulo. Esto da como resultado una variable fmdev->resp_skb no válida que pasa la verificación de validez. Como se ve en la parte posterior de la función, skb = fmdev->resp_skb; cuando la fmdev->resp_skb no válida pasa la verificación, puede ocurrir un error de desreferencia de puntero nulo en la línea 478, evt_hdr = (void *)skb->data; Para solucionar este problema, se recomienda incluir la comprobación de validez de fmdev->resp_skb dentro de la sección bloqueada de la función. Esta modificación garantiza que el valor de fmdev->resp_skb no cambie durante el proceso de validación, manteniendo así su validez. Este posible error se detecta mediante una herramienta de análisis estático experimental desarrollada por nuestro equipo. Esta herramienta analiza las API de bloqueo para extraer pares de funciones que se pueden ejecutar simultáneamente y, a continuación, analiza las instrucciones en las funciones emparejadas para identificar posibles errores de concurrencia, incluidas las ejecucións de datos y las violaciones de atomicidad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries: Se corrige que dtl_access_lock sea un rw_semaphore. El dtl_access_lock debe ser un rw_sempahore, un bloqueo inactivo, porque el código llama a kmalloc() mientras lo mantiene, lo que puede inactivar: # echo 1 > /proc/powerpc/vcpudispatch_stats ERROR: función inactiva llamada desde un contexto no válido en include/linux/sched/mm.h:337 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh preempt_count: 1, expected: 0 3 bloqueos mantenidos por sh/199: #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, en: vfs_write+0x324/0x438 #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, en: vcpudispatch_stats_write+0xd4/0x5f4 #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, en: vcpudispatch_stats_write+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh No contaminado 6.10.0-rc4 #152 Nombre del hardware: IBM pSeries (emulado por qemu) POWER9 (sin procesar) 0x4e1202 0xf000005 de:SLOF,HEAD hv:linux,kvm Rastreo de llamadas de pSeries: dump_stack_lvl+0x130/0x148 (no confiable) __might_resched+0x174/0x410 kmem_cache_alloc_noprof+0x340/0x3d0 alloc_dtl_buffers+0x124/0x1ac vcpudispatch_stats_write+0x2a8/0x5f4 proc_reg_write+0xf4/0x150 vfs_write+0xfc/0x438 ksys_write+0x88/0x148 excepción_de_llamada_al_sistema+0x1c4/0x5a0 llamada_al_sistema_común+0xf4/0x258

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: Se corrige el bucle de entradas SG en cola. El dwc3_request->num_queued_sgs se reduce al completarse. Si se gestiona una solicitud parcialmente completada, entonces el dwc3_request->num_queued_sgs ya no refleja el número total de num_queued_sgs (se borraría). Verifique correctamente el número de entradas SG de solicitud que quedan por preparar y poner en cola. Si no lo hace, puede causar una desreferencia de puntero nulo al acceder a una entrada SG inexistente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: Corrige el problema de asignación de memoria en amdgpu_discovery_get_nps_info() Corrige dos problemas con la asignación de memoria en amdgpu_discovery_get_nps_info() para mem_ranges: - Añade una comprobación de fallos de asignación para evitar desreferenciar un puntero nulo. - Como lo sugirió Christophe, utiliza kvcalloc() para la asignación de memoria, que comprueba si hay desbordamiento de multiplicación. Además, asigna los parámetros de salida nps_type y range_cnt después de la llamada a kvcalloc() para evitar modificar los parámetros de salida en caso de que se devuelva un error.

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: núcleo: se ha corregido una posible desreferenciación NULL causada por kunit_kzalloc() kunit_kzalloc() puede devolver un puntero NULL, desreferenciarlo sin la comprobación NULL puede provocar una desreferencia NULL. Se han añadido comprobaciones NULL para todos los kunit_kzalloc() en sound_kunit.c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Uso de asignación dinámica para la matriz de ocupación de CU en 'kfd_get_cu_occupancy()' La función `kfd_get_cu_occupancy` declaró anteriormente una matriz `cu_occupancy` grande como una variable local, lo que podría provocar desbordamientos de pila debido al uso excesivo de la pila. Esta confirmación reemplaza la asignación de matriz estática con asignación de memoria dinámica utilizando `kcalloc`, lo que reduce el tamaño de la pila. Este cambio evita el riesgo de desbordamientos de pila en el espacio del kernel, en escenarios donde `AMDGPU_MAX_QUEUES` es grande. La memoria asignada se libera utilizando `kfree` antes de que la función regrese para evitar fugas de memoria. Corrige lo siguiente con gcc W=1: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: En la función 'kfd_get_cu_occupancy': drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:322:1: advertencia: el tamaño del marco de 1056 bytes es mayor que 1024 bytes [-Wframe-larger-than=] 322 | } | ^

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: se corrige el bloqueo recursivo cuando el programa de veredicto devuelve SK_PASS Cuando el programa stream_verdict devuelve SK_PASS, coloca el skb recibido en su propia cola de recepción, pero finalmente se produce un bloqueo recursivo que provoca un bloqueo del sistema operativo. Este problema ha estado presente desde la versión v6.9. ''' sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # ahora stream_verdict devuelve SK_PASS sin asignación de sock de pares __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= bloqueo muerto ''' Este tema se ha discutido antes, pero no se ha solucionado. Discusión anterior: https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en el nodo blkaddr en truncate_node() syzbot informa un error de f2fs como se muestra a continuación: ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Seguimiento de llamadas: truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909 f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986 f2fs_create+0x357/0x530 fs/f2fs/namei.c:394 lookup_open fs/namei.c:3595 [en línea] open_last_lookups fs/namei.c:3694 [en línea] path_openat+0x1c03/0x3590 fs/namei.c:3930 do_filp_open+0x235/0x490 fs/namei.c:3960 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 do_sys_open fs/open.c:1430 [en línea] __do_sys_openat fs/open.c:1446 [en línea] __se_sys_openat fs/open.c:1441 [en línea] __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 La causa raíz es: en una imagen con errores, blkaddr en la entrada nat puede estar dañado, luego causará un pánico del sistema al usarlo en f2fs_invalidate_blocks(), para evitar esto, agreguemos una verificación de cordura en nat blkaddr en truncar_nodo().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device Si bien en cuanto al diseño la idea de convertir el controlador para usar la jerarquía de los chips IRQ es correcta, la implementación tiene fallas (heredadas). Esto se reveló cuando platform_get_irq() había iniciado WARN() en IRQ 0, que se supone que es un número IRQ de Linux (también conocido como vIRQ). Reelabore el controlador para respetar el dominio IRQ al crear cada dispositivo MFD por separado, ya que el dominio no es el mismo para todos ellos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: brd: aplazar la creación automática de discos hasta que la inicialización del módulo tenga éxito. Mi colega Wupeng encontró los siguientes problemas durante la inyección de fallas: ERROR: no se puede gestionar la falla de página para la dirección: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe No contaminado 6.12.0-rc3+ #17 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__asan_load8+0x4c/0xa0 ... Seguimiento de llamadas: blkdev_put_whole+0x41/0x70 bdev_release+0x1a3/0x250 blkdev_release+0x11/0x20 __fput+0x1d7/0x4a0 task_work_run+0xfc/0x180 syscall_exit_to_user_mode+0x1de/0x1f0 do_syscall_64+0x6b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e loop_init() está llamando a loop_add() después de que __register_blkdev() tenga éxito e ignora el error de disk_add() de loop_add(), ya que el error de loop_add() no es fatal y los discos creados correctamente ya están visibles para bdev_open().brd_init() actualmente está llamando a brd_alloc() antes de que __register_blkdev() tenga éxito y está liberando discos creados exitosamente cuando brd_init() devuelve un error. Esto puede causar UAF para los últimos dos casos: caso 1: T1: modprobe brd brd_init brd_alloc(0) // éxito add_disk disk_scan_partitions bdev_file_open_by_dev // asignar archivo fput // no se liberará hasta que regrese al espacio de usuario brd_alloc(1) // falló debido a un error de asignación de memoria inject // error la ruta para modprobe liberará el segmento de código // de regreso al espacio de usuario __fput blkdev_release bdev_release blkdev_put_whole bdev->bd_disk->fops->release // fops está liberado ahora, ¡UAF! caso 2: T1: T2: modprobe brd brd_init brd_alloc(0) // éxito open(/dev/ram0) brd_alloc(1) // error // ruta de error para modprobe close(/dev/ram0) ... /* UAF! */ bdev->bd_disk->fops->release Solucione este problema siguiendo lo que hace loop_init(). Además, vuelva a introducir brd_devices_mutex para ayudar a serializar las modificaciones a brd_list.