Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "ALSA: firewire-lib: operar durante el evento transcurrido en el contexto del proceso" commit 7ba5ca32fe6e ("ALSA: firewire-lib: operar durante el evento transcurrido en el contexto del proceso") eliminada la cola de trabajo del contexto del proceso de amdtp_domain_stream_pcm_pointer() y update_pcm_pointers() para eliminar su sobrecarga. Con RME Fireface 800, esto condujo a una regresión desde Kernels 5.14.0, lo que provocó una competencia de punto muerto AB/BA para el bloqueo de substream con una eventual congelación del sistema bajo la operación ALSA: subproceso 0: * (bloqueo A) adquiere el bloqueo de substream mediante snd_pcm_stream_lock_irq() en snd_pcm_status64() * (bloqueo B) espere a que finalice el tasklet llamando a tasklet_unlock_spin_wait() en tasklet_disable_in_atomic() en ohci_flush_iso_completions() del subproceso 1 de ohci.c: * (bloqueo B) ingrese al tasklet * (bloqueo A) intente adquirir el subflujo bloquear, esperando a que se libere: snd_pcm_stream_lock_irqsave() en snd_pcm_period_elapsed() en update_pcm_pointers() en Process_ctx_payloads() en Process_rx_packets() de amdtp-stream.c? tasklet_unlock_spin_wait ohci_flush_iso_completions firewire_ohci amdtp_domain_stream_pcm_pointer snd_firewire_lib snd_pcm_update_hw_ptr0 snd_pcm snd_pcm_status64 snd_pcm ? nativo_queued_spin_lock_slowpath _raw_spin_lock_irqsave snd_pcm_period_elapsed snd_pcm Process_rx_packets snd_firewire_lib irq_target_callback snd_firewire_lib handle_it_packet firewire_ohci context_tasklet firewire_ohci Restaurar la cola de trabajo del contexto del proceso para evitar un punto muerto Competencia de punto muerto AB/BA para el bloqueo de subtransmisión ALSA de snd_pcm_stream_lock_irq() en snd_pcm_status64() y snd_pcm_stream_lock_irqsave() en snd_pcm_period_elapsed(). revertir el commit 7ba5ca32fe6e ("ALSA: firewire-lib: operar durante el evento de período transcurrido en el contexto del proceso") Reemplace la descripción en línea para evitar futuros interbloqueos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvme-pci: agrega condición faltante para verificar la existencia de datos mapeados. Se llama a nvme_map_data() cuando la solicitud tiene segmentos físicos, por lo tanto, nvme_unmap_data() debe tener la misma condición para evitar la desreferencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu: sprd: Evite la deref NULL en sprd_iommu_hw_en En sprd_iommu_cleanup() antes de llamar a la función sprd_iommu_hw_en() dom->sdev es igual a NULL, lo que conduce a una desreferencia nula. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mISDN: corrige un use after free en hfcmulti_tx() No elimine la referencia a *sp después de llamar a dev_kfree_skb(*sp).

El complemento BackWPup para WordPress es vulnerable a Directory Traversal en versiones hasta la 4.0.1 incluida a través de la carpeta de copia de seguridad específica del trabajo. Esto permite a los atacantes autenticados almacenar copias de seguridad en carpetas arbitrarias en el servidor, siempre que el servidor pueda escribir en ellas. Además, la configuración predeterminada colocará un archivo index.php y .htaccess en el directorio elegido (a menos que ya esté presente) cuando se ejecute el primer trabajo de copia de seguridad, cuyo objetivo es evitar la lista de directorios y el acceso a archivos. Esto significa que un atacante podría establecer el directorio de respaldo en la raíz de otro sitio en un entorno compartido y así desactivar ese sitio.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/v3d: validar los identificadores pasados de drm syncobj en la extensión de rendimiento. Si el espacio de usuario proporciona un identificador desconocido o no válido en cualquier parte de la matriz de identificadores, el resto del controlador no lo manejará tan bien. Arréglelo comprobando que el identificador se haya buscado correctamente o, de lo contrario, falle la extensión saltando al desenrollado existente. (cereza escogida del commit a546b7e4d73c23838d7e4d2c92882b3ca902d213)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/v3d: validar los identificadores pasados de drm syncobj en la extensión de marca de tiempo. Si el espacio de usuario proporciona un identificador desconocido o no válido en cualquier parte de la matriz de identificadores, el resto del controlador no lo manejará tan bien. Arréglelo comprobando que el identificador se haya buscado correctamente o, de lo contrario, falle la extensión saltando al desenrollado existente. (cereza escogida del commit 8d1276d1b8f738c3afe1457d4dff5cc66fc848a3)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/v3d: corrige una posible pérdida de memoria en la extensión de rendimiento. Si falla la recuperación de la memoria del espacio de usuario durante el bucle principal, todos los objetos de sincronización de drm buscados hasta ese punto se filtrarán debido a la falta drm_syncobj_put. Solucionarlo exportando y utilizando un asistente de limpieza común. (cereza escogida del commit 484de39fa5f5b7bd0c5f2e2c5265167250ef7501)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/v3d: corrige una posible pérdida de memoria en la extensión de marca de tiempo. Si falla la recuperación de la memoria del espacio de usuario durante el bucle principal, todos los objetos de sincronización de drm buscados hasta ese punto se filtrarán debido a la falta drm_syncobj_put. Solucionarlo exportando y utilizando un asistente de limpieza común. (cereza escogida del commit 753ce4fea62182c77e1691ab4f9022008f25b62e)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: evita el acceso fuera de los límites en las extensiones de consulta de rendimiento. Verifique que la cantidad de espacio de usuario de perfmons que se pasa en las extensiones de copia y restablecimiento no sea mayor que el almacenamiento interno del kernel donde se encuentra el Los identificadores se copiarán. (cereza escogida del commit f32b5128d2c440368b5bf3a7a356823e235caabb)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: haga que cow_file_range_inline() respete la página bloqueada en caso de error. La ruta de escritura almacenada en el búfer de btrfs pasa por __extent_writepage(), que tiene un manejo complicado del valor de retorno para writepage_delalloc(). Específicamente, cuando eso devuelve 1, salimos, pero para otros valores de retorno continuamos y terminamos llamando a btrfs_folio_end_all_writers(). Si la publicación se ha desbloqueado (tenga en cuenta que verificamos el bit PageLocked al inicio de __extent_writepage()), esto resulta en un pánico de afirmación como este de syzbot: BTRFS: error (device loop0 state EAL) in free_log_tree:3267: errno = -5 Fallo de E/S Advertencia BTRFS (estado EAL del bucle 0 del dispositivo): omitir El commit de la transacción abortada. BTRFS: error (EAL de estado de bucle 0 del dispositivo) en cleanup_transaction:2018: errno=-5 Error de aserción de E/S fallida: folio_test_locked(folio), en fs/btrfs/subpage.c:871 ------------ [cortar aquí]------------ ¡ERROR del kernel en fs/btrfs/subpage.c:871! Vaya: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 5090 Comm: syz-executor225 No está contaminado 6.10.0-syzkaller-05505-gb1bc554e009e #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/06/2024 RIP: 0010:btrfs_folio_end_all_writers+0x55b/0x610 fs/btrfs/subpage.c:871 Código: e9 d3 fb ff ff e8 25 22 c2 fd 48 c7 c7 c0 3c 0e 8c 48 c7 c6 80 3d 0e 8c 48 c7 c2 60 3c 0e 8c b9 67 03 00 00 e8 66 47 ad 07 90 <0f> 0b e8 6e 45 b0 07 4c 89 ff be 08 00 00 00 e8 21 12 25 fe 4c 89 RSP: 00033d72e0 EFLAGS: 00010246 RAX: 0000000000000045 RBX: 00fff0000000402c RCX: 663b7a08c50a0a00 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 000000000 0000000 RBP: ffffc900033d73b0 R08: ffffffff8176b98c R09: 1ffff9200067adfc R10: dffffc0000000000 R11: fffff5200067adfd R12: 0000000000000001 R13: 0000000000 R14: 0000000000000000 R15: ffffea0001cbee80 FS: 0000000000000000( 0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5f076012f8 CR3: e134000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __extent_writepage fs/btrfs/extent_io.c:1597 [en línea] extend_write_cache_pages fs/btrfs/extent_io.c:2251 [en línea] btrfs_writepages+0x14d7/0x2760 fs/btrfs/extent_io.c:2373 do_writepages+0x359/ 0x870 mm/page-writeback.c:2656 filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397 __filemap_fdatawrite_range mm/filemap.c:430 [en línea] __filemap_fdatawrite mm/filemap.c:436 [en línea] filemap_flush+0xdf/0x130 mm /filemap.c:463 btrfs_release_file+0x117/0x130 fs/btrfs/file.c:1547 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:222 exit_task_work include/linux/task_work .h:40 [en línea] do_exit+0xa2f/0x27f0 kernel/exit.c:877 do_group_exit+0x207/0x2c0 kernel/exit.c:1026 __do_sys_exit_group kernel/exit.c:1037 [en línea] __se_sys_exit_group kernel/exit.c:1035 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1035 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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: 0033:0x7f5f075b70c9 Código: No se puede acceder a los bytes del código de operación en 0x7f5f075b709f. Me encontré con el mismo problema al realizar cientos de ejecuciones aceleradas de generic/475, que también genera errores de IO por diseño. Instrumenté ese reproductor con bpftrace y descubrí que el folio_unlock no deseado provenía de la siguiente pila de llamadas: folio_unlock+5 __process_pages_contig+475 cow_file_range_inline.constprop.0+230 cow_file_range+803 btrfs_run_delalloc_range+566 writepage_delalloc+332 __extent_writepage # ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: proteger la recuperación de ->fd[fd] en do_dup2() de predicciones erróneas; ambos llamadores han verificado que fd no es mayor que ->max_fds; sin embargo, una predicción errónea podría terminar con tofree = fdt->fd[fd]; siendo ejecutado especulativamente. Eso está mal por las mismas razones por las que está mal en close_fd()/file_close_fd_locked(); se aplica la misma solución: array_index_nospec(fd, fdt->max_fds) podría diferir de fd solo en caso de ejecución especulativa en una ruta mal prevista.