Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dyndbg: corrige el antiguo BUG_ON en >control parser. Corrige un BUG_ON de 2009. Incluso si parece "unreachable" (realmente no lo miré), asegurémonos eliminándolo. haciendo pr_err y devuelve -EINVAL en su lugar.

Se encontró una vulnerabilidad en SourceCodester Simple Inventory System 1.0. Ha sido clasificada como crítica. Una parte desconocida del archivo tableedit.php afecta a esta vulnerabilidad. La manipulación del argumento from/to conduce a la inyección SQL. Es posible iniciar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador asociado de esta vulnerabilidad es VDB-265083.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: phy_device: previene excepciones nullptr en ISR. Si phydev->irq está configurado incondicionalmente, verifique si hay un controlador de interrupciones válido o recurra al modo de sondeo para evitar excepciones nullptr en la rutina del servicio de interrupciones .

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: corrige el acceso al puntero null al cancelar el escaneo. Durante la cancelación del escaneo podríamos usar vif que no estaban escaneando. Solucione este problema utilizando el vif de escaneo real.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: VMCI: corrigió la advertencia de tiempo de ejecución de memcpy() en dg_dispatch_as_host() Syzkaller presionó el error 'ADVERTENCIA en dg_dispatch_as_host'. memcpy: se detectó escritura que abarca todos los campos (tamaño 56) de un solo campo "&dg_info->msg" en drivers/misc/vmw_vmci/vmci_datagram.c:237 (tamaño 24) ADVERTENCIA: CPU: 0 PID: 1555 en drivers/misc/vmw_vmci /vmci_datagram.c:237 dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237 Algunos comentarios de código, según tengo entendido: 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size ) /// Esto es 24 + payload_size memcpy(&dg_info->msg, dg, dg_size); Destino = dg_info->msg ---> esta es una estructura de 24 bytes (struct vmci_datagram) Fuente = dg --> esta es una estructura de 24 bytes (struct vmci_datagram) Tamaño = dg_size = 24 + payload_size {payload_size = 56-24 = 32} -- Syzkaller logró establecer payload_size en 32. 35 struct delay_datagram_info { 36 struct datagram_entry *entry; 37 struct work_struct work; 38 bool in_dg_host_queue; 39 /* msg y msg_payload deben estar juntos. */ 40 struct vmci_datagram mensaje; 41 u8 msg_payload[]; 42}; Entonces, esos bytes adicionales de payload se copian en msg_payload[], se ve una advertencia de tiempo de ejecución mientras se utiliza Syzkaller. Una forma posible de solucionar la advertencia es dividir memcpy() en dos partes: una, asignación directa del mensaje y la segunda, encargada del payload. Gustavo citó: "Bajo FORTIFY_SOURCE no debemos copiar datos entre varios miembros de una estructura".

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: lpfc: corrige una posible pérdida de memoria en lpfc_rcv_padisc() La llamada a lpfc_sli4_resume_rpi() en lpfc_rcv_padisc() puede devolver un estado fallido. En tales casos, no se emite elsiocb, no se llama a la finalización y, por lo tanto, se filtra el recurso elsiocb. Verifique el valor de retorno después de llamar a lpfc_sli4_resume_rpi() y libere condicionalmente el recurso elsiocb.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: Omitir el restablecimiento de la ranura de error PCI durante la recuperación de RAS Por qué: El restablecimiento de la ranura de error PCI puede activarse después de inyectar ue en UMC varias veces, lo que provocó que el sistema se bloqueara. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: el reinicio de la GPU se realizó correctamente, intentando reanudar [ 557.373718] [drm] PCIE GART de 512M habilitado. [ 557.373722] [drm] PTB ubicado en 0x0000031FED700000 [ 557.373788] [drm] ¡La VRAM se pierde debido al reinicio de la GPU! [ 557.373789] [drm] PSP se está reanudando... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Estado del dispositivo = 1 pci_status: 0. Salir, resultado = 3, es necesario restablecer [ 557.547067] [drm] Error de PCI: devolución de llamada detectada , estado(1)!! [ 557.547069] [drm] Aún no hay soporte para XGMI hive... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Estado del dispositivo = 1 pci_status: 0. Ingrese [ 557.607763] mlx5_core 0000:55:00.0: espere el valor del contador vital 0x16b5b después de 1 iteración [557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Estado del dispositivo = 1 pci_status: 1. Salir, err = 0, resultado = 5, recuperado [557.610492] [drm] Error de PCI: ¡devolución de llamada de restablecimiento de ranura! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: ¡El reinicio de GPU (2) se realizó correctamente! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: ¡El reinicio de GPU (2) se realizó correctamente! [ 560.689562] falla de protección general, probablemente para dirección no canónica 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic # 101-Ubuntu [ 560.712057] Nombre de hardware: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 08/11/2023 [ 560.720959] Cola de trabajo: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu] [ 87] QEPD: 0010: amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Código: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 00010202 [560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] BP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 000 [560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000ffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Seguimiento de llamadas: [ 560.849225] [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea [560.856488]? show_trace_log_lvl+0x1d6/0x2ea [560.861379]? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? show_regs.part.0+0x23/0x29 [560.872293]? __die_body.cold+0x8/0xd [ 560.876502] ? die_addr+0x3e/0x60 [ 560.880238] ? exc_general_protection+0x1c5/0x410 [560.885532]? asm_exc_general_protection+0x27/0x30 [560.891025]? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.904520] Process_one_work+0x228/0x3d0 Cómo: En la recuperación de RAS, el restablecimiento del modo 1 se emite desde RAS fatal manejo de errores y esperaba todos los nodos en una colmena que se van a restablecer. no es necesario emitir otro modo-1 durante este procedimiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vc4: no comprobar si plano->estado->fb == estado->fb Actualmente, al usar confirmaciones sin bloqueo, podemos ver la siguiente advertencia del kernel : [110.908514] ------------[ cortar aquí ]------------ [ 110.908529] refcount_t: subdesbordamiento; uso después de la liberación. [110.908620] ADVERTENCIA: CPU: 0 PID: 1866 en lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [110.908664] Módulos vinculados en: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes _arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm 2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) 2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks retroiluminación ip_tables x_tables ipv6 [110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Contaminado: GC 6.1.66 -v8+ #32 [110.909104] Nombre del hardware: Frambuesa Pi 3 Modelo B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one + 0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205 ] x26: 0000000000000002 x25: 00000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: [110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 00000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 00000000000000027 x9: c912d0d083728c00 [110.909359] x8: c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 00000000000000000 [ 110.909409] x2 : 00000000000 x1: ffffffc00913b750 x0: 0000000000000001 [110.909434] Rastreo de llamadas: [110.909441] refcount_dec_not_one+0xb8/0xc0 [110.909461] / 0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] 0/0x9dc [vc4] [110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [110.911397 ] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330 ] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/ 0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]--- Esto sucede porque, aunque `prepare_fb` y `cleanup_fb` están perfectamente equilibrados, no podemos garantizar la coherencia en el plano de verificación->estado ->fb == estado->fb. Esto significa que a veces podemos aumentar el recuento en `prepare_fb` y no disminuirlo en `cleanup_fb`. Lo contrario también puede ser cierto. De hecho, no se debe acceder directamente a la estructura drm_plane .state, sino que se debe utilizar la función auxiliar `drm_atomic_get_new_plane_state()`. Entonces, podríamos ceñirnos a esta verificación, pero usando `drm_atomic_get_new_plane_state()`. Pero en realidad, esta verificación no se re---trunca---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath11k: reduce la longitud del búfer del canal MHI a 8 KB Actualmente, el campo buf_len de ath11k_mhi_config_qca6390 está asignado con 0, lo que hace que MHI use un tamaño predeterminado, 64 KB, para asignar búferes de canal. Es probable que esto falle en algunos escenarios donde la memoria del sistema está muy fragmentada y no se permite la compactación o recuperación de memoria. Hay un informe de error causado por esto: kworker/u32:45: error de asignación de página: orden:4, modo:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 19318 Comm: kworker/u32:45 No contaminado 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (inédito) 493b6d5b382c603654d7a81fc3c144d59a1dfceb Cola de trabajo: events_unbound async_run_entry_fn Seguimiento de llamadas: dump_stack_lvl+0x47/0x60 warn_alloc+0x13a/ 0x1b0? srso_alias_return_thunk+0x5/0xfbef5? __alloc_pages_direct_compact+0xab/0x210 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0 __alloc_pages+0x32d/0x350 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __kmalloc_large_node+0x72/0x110 __kmalloc+0x37c/0x480 ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a78 14] __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] device_for_each_child+0x5c/0xa0 ? __pfx_pci_pm_resume+0x10/0x10 ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]? srso_alias_return_thunk+0x5/0xfbef5 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]? srso_alias_return_thunk+0x5/0xfbef5 dpm_run_callback+0x8c/0x1e0 device_resume+0x104/0x340? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x32/0x120 Process_one_work+0x168/0x330 Workers_thread+0x2f5/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe8/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 En realidad, esos buffers son utilizados solo por la comunicación QMI destino -> host. Y para WCN6855 y QCA6390, el tamaño de paquete más grande es inferior a 6 KB. Entonces cambie el campo buf_len a 8 KB, lo que da como resultado una asignación de orden 1 si el tamaño de la página es 4 KB. De esta manera, al menos podemos ahorrar algo de memoria y también disminuir la posibilidad de que se produzca un error en la asignación en esos escenarios. Probado en: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-direct: páginas filtradas en el fallo de dma_set_decrypted() En TDX es posible que el host que no es de confianza provoque que set_memory_encrypted() o set_memory_decrypted() falle de modo que se devuelva un error y la memoria resultante se comparte. Las personas que llaman deben tener cuidado al manejar estos errores para evitar devolver memoria descifrada (compartida) al asignador de páginas, lo que podría provocar problemas funcionales o de seguridad. DMA podría liberar páginas descifradas/compartidas si dma_set_decrypted() falla. Este debería ser un caso raro. En este caso, simplemente filtre las páginas en lugar de liberarlas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pstore/zone: agregue una verificación de puntero null a psz_kmsg_read kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación haya sido exitosa verificando la validez del puntero.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: skbuff: agregar verificación de depuración de desbordamiento a los asistentes de extracción/empuje syzbot logró activar el siguiente símbolo: BUG: KASAN: use after free en __skb_flow_dissect+0x4a3b/0x5e50 Lectura de tamaño 1 en la dirección ffff888208a4000e por tarea a.out/2313 [..] __skb_flow_dissect+0x4a3b/0x5e50 __skb_get_hash+0xb4/0x400 ip_tunnel_xmit+0x77e/0x26f0 ipip_tunnel_xmit+0x298/0x410 .. El análisis muestra que el skb tiene un ->head válido, pero falso ->puntero de datos. skb->data obtiene su valor falso a través de la capa vecina, que hace: 1556 __skb_pull(skb, skb_network_offset(skb)); ... y el skb ya era dudoso en este punto: skb_network_offset(skb) devuelve un valor negativo debido a un desbordamiento anterior de skb->network_header (u16). __skb_pull por lo tanto "ajusta" los datos skb-> con un desplazamiento enorme, apuntando fuera del área principal de skb->. Permitir que las compilaciones de depuración se ejecuten cuando intentamos extraer/enviar más de INT_MAX bytes. Después de esto, el reproductor syzkaller produce un sonido más preciso antes de que el disector de flujo intente leer skb->memoria de datos: ADVERTENCIA: CPU: 5 PID: 2313 en include/linux/skbuff.h:2653 neigh_connected_output+0x28e/0x400 ip_finish_output2+ 0xb25/0xed0 iptunnel_xmit+0x4ff/0x870 ipgre_xmit+0x78e/0xbb0