Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb: scarlett2: Se corrige la falta de comprobación de valores NULL. scarlett2_input_select_ctl_info() configura las matrices de cadenas asignadas mediante kasprintf(), pero omite las comprobaciones de valores NULL, lo que puede provocar una desreferencia de valores NULL. ¡Uy! Añadamos la comprobación de valores NULL adecuada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: imx95-blk-ctl: Corregir aborto sincrónico. Al habilitar PM en tiempo de ejecución para proveedores de reloj que también pertenecen a un dominio de energía, se produce el siguiente fallo: error: aborto externo sincrónico: 0000000096000010 [#1] PREEMPT SMP Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : clk_mux_get_parent+0x60/0x90 lr : clk_core_reparent_orphans_nolock+0x58/0xd8 Rastreo de llamadas: clk_mux_get_parent+0x60/0x90 clk_core_reparent_orphans_nolock+0x58/0xd8 of_clk_add_hw_provider.part.0+0x90/0x100 of_clk_add_hw_provider+0x1c/0x38 imx95_bc_probe+0x2e0/0x3f0 platform_probe+0x70/0xd8 Al habilitar el PM en tiempo de ejecución sin reanudar explícitamente el dispositivo, se interrumpió el dominio de energía después de llamar a clk_register(). Como resultado, se produce un fallo cuando se agrega el proveedor de hardware de reloj e intenta acceder al registro BLK_CTL. Para solucionar esto, use devm_pm_runtime_enable() en lugar de pm_runtime_enable() y elimine pm_runtime_disable() en la ruta de limpieza.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: compress: fix UAF de f2fs_inode_info en f2fs_free_dic El decompress_io_ctx puede liberarse de forma asíncrona tras la finalización de la E/S. Si este archivo se elimina inmediatamente después de la lectura, y el kworker del procesamiento de post_read_wq aún no se ha ejecutado debido a las altas cargas de trabajo, es posible que el inodo (f2fs_inode_info) se desaloje y se libere antes de que se use f2fs_free_dic. El caso de UAF como se muestra a continuación: Hilo A Hilo B - f2fs_decompress_end_io - f2fs_put_dic - queue_work añadir trabajo free_dic a post_read_wq - do_unlink - iput - evict - call_rcu Este archivo se elimina tras la lectura. Hilo C kworker para procesar post_read_wq - rcu_do_batch - f2fs_free_inode - kmem_cache_free inodo liberado por rcu - process_scheduled_works - f2fs_late_free_dic - f2fs_free_dic - f2fs_release_decomp_mem lectura (dic->inode)->i_compress_algorithm). Este parche almacena compress_algorithm y sbi en dic para evitar el UAF del inodo. Además, la solución anterior está obsoleta en [1] y puede causar un bloqueo del sistema. [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org

En mupen64plus v2.6.0 hay una vulnerabilidad de desbordamiento de matriz en las funciones write_rdram_regs y write_rdram_regs, que permite ejecutar comandos arbitrarios en la máquina host.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: pnv_php: Limpiar las IRQ asignadas al desconectar Cuando se desconecta la raíz de una configuración de puente PCIe anidada, el controlador pnv_php filtró los recursos IRQ asignados para las notificaciones de eventos de conexión en caliente de los puentes secundarios, lo que resultó en un pánico. Corrija esto recorriendo todos los buses secundarios y desasignando todos sus recursos IRQ antes de llamar a pci_hp_remove_devices(). También modifique el tiempo de vida de la cola de trabajo en struct pnv_php_slot::wq para que solo se destruya en pnv_php_free_slot(), en lugar de pnv_php_disable_irq(). Esto es necesario ya que pnv_php_disable_irq() ahora será llamado por trabajadores activados por interrupciones de desconexión en caliente, por lo que la cola de trabajo debe permanecer asignada. El pánico del kernel abreviado que ocurre sin este parche es el siguiente: ADVERTENCIA: CPU: 0 PID: 687 en kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash No contaminado 6.14.0-rc5+ #2 Seguimiento de llamadas: msi_device_data_release+0x34/0x9c (no confiable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_ranura_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec [bhelgaas: comentarios ordenados]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: pnv_php: Arreglar la detección y recuperación de conexiones sorpresivas El código de conexión en caliente PowerNV existente no manejaba correctamente los eventos de conexión sorpresiva, lo que provocaba un fallo completo del sistema de conexión en caliente tras la extracción del dispositivo y un reinicio necesario para detectar nuevos dispositivos. Esto se reduce a dos problemas: 1) Cuando se extrae un dispositivo por sorpresa, a menudo el puerto ascendente del puente provocará una congelación del PE en el PHB. Si esta congelación no se elimina, el kernel no recibirá las interrupciones MSI de la lógica de notificación de conexión en caliente del puente, lo que detendrá todos los eventos de conexión en todas las ranuras asociadas con el PE. 2) Cuando se extrae un dispositivo de una ranura, independientemente de si es una extracción sorpresiva o programática, el PHB/PE asociado queda congelado. Si esta congelación no se elimina mediante un reinicio fundamental, skiboot no puede eliminar la congelación y no puede volver a entrenar/escanear la ranura. Esto también requiere un reinicio para eliminar la congelación y volver a detectar el dispositivo en la ranura. Emita los comandos de descongelación y reescaneo adecuados en eventos de conexión en caliente, y no falle en la conexión en caliente si pci_bus_to_OF_node() devuelve NULL. [bhelgaas: comentarios ordenados]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: descartar paquetes UFO en udp_rcv_segment() Al enviar un paquete con virtio_net_hdr a un dispositivo tun, si gso_type en virtio_net_hdr es SKB_GSO_UDP y gso_size es menor que el tamaño de udphdr, puede ocurrir el siguiente bloqueo. ------------[ cortar aquí ]------------ ¡ERROR del kernel en net/core/skbuff.c:4572! Oops: código de operación no válido: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest No contaminado 6.16.0-rc7 #203 PREEMPT(voluntario) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Código: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Rastreo de llamadas: udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 Para activar el segmento gso en udp_queue_rcv_skb(), también debemos configurar la opción UDP_ENCAP_ESPINUDP para habilitarla udp_sk(sk)->encap_rcv. Cuando el gancho encap_rcv devuelve 1 en udp_queue_rcv_one_skb(), udp_csum_pull_header() intentará extraer udphdr, pero el tamaño de skb se ha segmentado al tamaño de gso, lo que provoca este fallo. El commit anterior cf329aa42b66 ("udp: lidiar con la redirección de paquetes UDP GRO") introduce la segmentación en la ruta de recepción UDP solo para GRO, que nunca se concibió para UFO, por lo que se descartan los paquetes UFO en udp_rcv_segment().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: ti: j721e-csi2rx: corrección de corrupción de list_del. Si ti_csi2rx_start_dma() falla en ti_csi2rx_dma_callback(), el búfer se marca como terminado con VB2_BUF_STATE_ERROR, pero no se elimina de la cola de DMA. Esto provoca que se vuelva a intentar el mismo búfer en la siguiente iteración, lo que resulta en una doble iteración de list_del() y, finalmente, en corrupción de la lista. Para solucionar esto, elimine el búfer de la cola antes de llamar a vb2_buffer_done() en caso de error. Esto resuelve un fallo debido a la corrupción de list_del: [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048 [ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428) [ 37.850799] ------------[ cut here ]------------ [ 37.855424] kernel BUG at lib/list_debug.c:65! [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT) [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.914059] sp : ffff800080003db0 [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000 [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122 [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0 [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720 [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568 [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000 [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d [ 37.988832] Call trace: [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P) [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4 [ 38.001419] udma_vchan_complete+0x1e0/0x344 [ 38.005705] tasklet_action_common+0x118/0x310 [ 38.010163] tasklet_action+0x30/0x3c [ 38.013832] handle_softirqs+0x10c/0x2e0 [ 38.017761] __do_softirq+0x14/0x20 [ 38.021256] ____do_softirq+0x10/0x20 [ 38.024931] call_on_irq_stack+0x24/0x60 [ 38.028873] do_softirq_own_stack+0x1c/0x40 [ 38.033064] __irq_exit_rcu+0x130/0x15c [ 38.036909] irq_exit_rcu+0x10/0x20 [ 38.040403] el1_interrupt+0x38/0x60 [ 38.043987] el1h_64_irq_handler+0x18/0x24 [ 38.048091] el1h_64_irq+0x6c/0x70 [ 38.051501] default_idle_call+0x34/0xe0 (P) [ 38.055783] do_idle+0x1f8/0x250 [ 38.059021] cpu_startup_entry+0x34/0x3c [ 38.062951] rest_init+0xb4/0xc0 [ 38.066186] console_on_rootfs+0x0/0x6c [ 38.070031] __primary_switched+0x88/0x90 [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000) [ 38.080168] ---[ end trace 0000000000000000 ]--- [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 38.092197] SMP: stopping secondary CPUs [ 38.096139] Kernel Offset: disabled [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b [ 38.105202] Memory Limit: none [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: zloop: corrección del uso tras liberación de KASAN del conjunto de etiquetas. Al eliminar un dispositivo de bucle zonificado o un dispositivo zloop, el kernel habilitado para KASAN informa "BUG KASAN use after-free" en blk_mq_free_tag_set(). El error se produce porque zloop_ctl_remove() llama a put_disk(), que a su vez invoca zloop_free_disk(). zloop_free_disk() libera la memoria asignada al puntero zloop. Sin embargo, una vez liberada la memoria, zloop_ctl_remove() llama a blk_mq_free_tag_set(&zlo->tag_set), que accede al puntero zloop liberado. De ahí use-after-free de KASAN. Para evitar el error, mueva la llamada a blk_mq_free_tag_set(&zlo->tag_set) de zloop_ctl_remove() a zloop_free_disk(). Esto garantiza que el conjunto de etiquetas se libere antes de la llamada a kvfree(zlo).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: hacer que rdev_addable sea utilizable para el modo rcu Nuestro caso de prueba activa el pánico: ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 No contaminado 6.16.0+ #94 PREEMPT(none) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 01/04/2014 Cola de trabajo: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Rastreo de llamadas: Módulos vinculados en: raid10 CR2: 00000000000000e0 ---[ fin de seguimiento 000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0 md_spares_need_change en md_start_sync llamará a rdev_addable que está protegido por rcu_read_lock/rcu_read_unlock. Este contexto rcu ayudará a proteger rdev, ya que no se liberará, pero rdev->mddev se establecerá en NULL antes de llamar a synchronize_rcu en md_kick_rdev_from_array. Para solucionar esto, use READ_ONCE y compruebe si rdev->mddev sigue activo.

spimsimulator spim v9.1.24 y anteriores son vulnerables a desbordamiento de búfer en READ_STRING_SYSCALL.

IBM QRadar SIEM 7.5 a 7.5.0 UP13 podría permitir que un usuario autenticado aumente sus privilegios a través de un cronjob mal configurado debido a la ejecución con privilegios innecesarios.