Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: mt8365-dai-i2s: pasar el tamaño correcto a mt8365_dai_set_priv. Dado mt8365_dai_set_priv, se asigna espacio priv_size para copiar priv_data, lo que significa que debemos pasar mt8365_i2s_priv[i] o "struct mtk_afe_i2s_priv" en lugar de afe_priv, cuyo tamaño es "struct mt8365_afe_private". De lo contrario, la queja de KASAN. [ 59.389765] ERROR: KASAN: global fuera de los límites en mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm] ... [ 59.394789] Rastreo de llamadas: [ 59.395167] dump_backtrace+0xa0/0x128 [ 59.395733] show_stack+0x20/0x38 [ 59.396238] dump_stack_lvl+0xe8/0x148 [ 59.396806] print_report+0x37c/0x5e0 [ 59.397358] kasan_report+0xac/0xf8 [ 59.397885] kasan_check_range+0xe8/0x190 [59.398485] asan_memcpy+0x3c/0x98 [59.399022] mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm] [59.399928] mt8365_dai_i2s_register+0x1e8/0x2b0 [snd_soc_mt8365_pcm] [59.400893] mt8365_afe_pcm_dev_probe+0x4d0/0xdf0 [snd_soc_mt8365_pcm] [59.401873] platform_probe+0xcc/0x228 [ 59.402442] really_probe+0x340/0x9e8 [ 59.402992] driver_probe_device+0x16c/0x3f8 [ 59.403638] driver_probe_device+0x64/0x1d8 [ 59.404256] driver_attach+0x1dc/0x4c8 [ 59.404840] bus_for_each_dev+0x100/0x190 [ 59.405442] driver_attach+0x44/0x68 [ 59.405980] bus_add_driver+0x23c/0x500 [ 59.406550] driver_register+0xf8/0x3d0 [ 59.407122] registro_del_controlador_de_plataforma+0x68/0x98 [59.407810] inicio_del_controlador_del_pcm_mt8365_afe+0x2c/0xff8 [snd_soc_mt8365_pcm]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: No más autorrecuperación. Cuando un nodo se retira y resulta ser el único que tiene montado el sistema de archivos, gfs2 intenta reproducir el diario local para restablecer la consistencia del sistema de archivos. Esto no solo es una pésima idea, sino que nunca ha funcionado, ya que gfs2_recover_func() se niega a hacer nada durante una retirada. Sin embargo, incluso antes de llegar a este punto, gfs2_recover_func() desreferencia sdp->sd_jdesc->jd_inode. Esto era un use-after-free antes del commit 04133b607a78 ("gfs2: Evitar doble entrada para el diario en caso de error") y, desde entonces, es una desreferencia de puntero nulo. Simplemente elimine la autorrecuperación para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: proc: usar el mismo tratamiento para verificar proc_lseek que para proc_read_iter, etc. Verificar pde->proc_ops->proc_lseek directamente puede causar UAF en el escenario rmmod. Se trata de una falla en proc_reg_open() después del commit 654b33ada4ab("proc: fix UAF in proc_get_inode()"). Siguiendo la sugerencia de AI Viro, se debe corregir de la misma manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar el acceso fuera de los límites en devs.path - touch /mnt/f2fs/0123456789012345678901234567890123456789012345678901234567890123 - truncate -s $((1024*1024*1024)) \ /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - touch /mnt/f2fs/file - truncate -s $((1024*1024*1024)) /mnt/f2fs/file - mkfs.f2fs /mnt/f2fs/0123456789012345678901234567890123456789012345678901234567890123 \ -c /mnt/f2fs/file - mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ /mnt/f2fs/loop [16937.192225] F2FS-fs (loop0): Montar dispositivo [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01, 511, 0 - 3ffff [16937.192268] F2FS-fs (loop0): Error al encontrar dispositivos Si la longitud de la ruta del dispositivo es igual a MAX_PATH_LEN, sbi->devs.path[] puede no terminar con un carácter nulo debido a que la matriz de ruta está completamente llena, por lo que accidentalmente, los campos ubicados después de path[] pueden tratarse como parte de la ruta del dispositivo, lo que da como resultado el análisis de una ruta de dispositivo incorrecta. Agreguemos un espacio de byte para que sbi->devs.path[] almacene el carácter nulo de la cadena de ruta del dispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: canaan: k230: Se corrige el orden del análisis de DT y el registro pinctrl. Se desplaza el análisis de DT antes del registro pinctrl. Esto garantiza que el análisis del árbol de dispositivos se realice antes de llamar a devm_pinctrl_register() para evitar el uso de recursos pin no inicializados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: canaan: k230: añadir comprobación NULL en el análisis DT. Se añade una comprobación NULL para el valor de retorno de of_get_property() al recuperar la propiedad "pinmux" en el analizador de grupo. Esto evita una posible desreferencia de puntero NULL si la propiedad no se encuentra en el nodo del árbol de dispositivos. También se corrige un error tipográfico ("sintenel") en el comentario de la tabla de coincidencias de ID de dispositivo, corrigiéndolo a "sentinel".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: Se corrige el código de error en iwl_op_mode_dvm_start(). Se conserva el código de error si iwl_setup_deferred_work() falla. El código actual devuelve ERR_PTR(0) (que es NULL) en esta ruta. Creo que la falta del código de error podría provocar un uso posterior a la liberación que involucre debugfs.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: mcc: impide el ajuste de turnos en rtw89_core_mlsr_switch(). El valor "link_id" proviene del usuario a través de debugfs. Si es mayor que BITS_PER_LONG, esto provocaría un ajuste de turnos y, potencialmente, un acceso fuera de los límites posteriormente. De hecho, podemos limitarlo a IEEE80211_MLD_MAX_NUM_LINKS (15). Afortunadamente, solo el usuario root puede escribir en archivos de debugfs, por lo que el impacto en la seguridad es mínimo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: pci-epf: No completar comandos dos veces si nvmet_req_init() falla. nvmet_req_init() y req->execute() completan los comandos fallidos. Descripción del problema: nvmet_req_init() llama internamente a __nvmet_req_complete() en caso de fallo (p. ej., un código de operación no compatible, que llama a la devolución de llamada "queue_response"). Esto provoca la llamada a nvmet_pci_epf_queue_response(), que a su vez llama a nvmet_pci_epf_complete_iod() si data_len es 0 o si dma_dir es diferente de DMA_TO_DEVICE. Esto genera una doble finalización, ya que nvmet_pci_epf_exec_iod_work() también llama a nvmet_pci_epf_complete_iod() cuando falla nvmet_req_init(). Pasos para reproducir: En el host, envíe un comando con un código de operación no compatible con nvme-cli. Por ejemplo, el comando de administrador "security receive": $ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096. Esto activa una doble finalización, ya que nvmet_req_init() falla y se llama a nvmet_pci_epf_queue_response(). En este caso, iod->dma_dir aún se encuentra en el estado predeterminado "DMA_NONE", tal como se establece por defecto en nvmet_pci_epf_alloc_iod(), por lo que se llama a nvmet_pci_epf_complete_iod(). Debido a que nvmet_req_init() falló, nvmet_pci_epf_complete_iod() también se llama en nvmet_pci_epf_exec_iod_work(), lo que provoca una doble finalización. Esto no solo envía dos finalizaciones al host, sino que también corrompe el estado del destino PCI NVMe, lo que provoca errores del kernel. Este parche permite que nvmet_req_init() y req->execute() completen todos los comandos fallidos y elimina el caso de doble finalización en nvmet_pci_epf_exec_iod_work(), corrigiendo así los casos extremos donde se producían dobles finalizaciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hfsplus: eliminar comprobación mutex_lock en hfsplus_free_extents Syzbot informó de un problema en el sistema de archivos hfsplus: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 4400 en fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0 Rastreo de llamadas: hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606 hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56 cont_expand_zero fs/buffer.c:2383 [en línea] cont_write_begin+0x2cf/0x860 fs/buffer.c:2446 hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52 generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347 hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263 notify_change+0xe38/0x10f0 fs/attr.c:420 do_truncate+0x1fb/0x2e0 fs/open.c:65 do_sys_ftruncate+0x2eb/0x380 fs/open.c:193 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Para evitar un bloqueo, el commit 31651c607151 ("hfsplus: evitar bloqueo al truncamiento de archivos") desbloquea el árbol externo antes de hfsplus_free_extents() y añade una comprobación de si el árbol externo está bloqueado en hfsplus_free_extents(). Sin embargo, cuando operaciones como hfsplus_file_release, hfsplus_setattr, hfsplus_unlink y hfsplus_get_block se ejecutan simultáneamente en archivos diferentes, es muy probable que se active WARN_ON, lo que hará que syzbot y xfstest lo consideren una anomalía. El comentario sobre esta advertencia también describe una de las situaciones de fácil activación, que puede fácilmente provocar que xfstest y syzbot reporten errores. [Tarea A] [Tarea B] ->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!! Varios subprocesos podrían intentar bloquear el árbol de extensiones compartidas. Una advertencia puede activarse en un subproceso cuando otro subproceso ha bloqueado el árbol. Este comportamiento del código es incorrecto y debemos eliminar la advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: stm32: Comprobar la disponibilidad de cfg en stm32_spi_probe La función stm32_spi_probe ahora incluye una comprobación para garantizar que el puntero devuelto por of_device_get_match_data no sea NULL antes de acceder a sus miembros. Esto resuelve una advertencia donde podría ocurrir una posible desreferencia de puntero NULL al acceder a cfg->has_device_mode. Antes de acceder al miembro 'has_device_mode', verificamos que 'cfg' no sea NULL. Si 'cfg' es NULL, se registra un mensaje de error. Este cambio garantiza que el controlador no intente acceder a los datos de configuración si no están disponibles, previniendo así un posible fallo del sistema debido a una desreferencia de puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: dts: qcom: qcs615: se corrige un problema de bloqueo causado por un bucle infinito para Coresight. Los dispositivos Coresight han creado un bucle infinito. Cuando solo se habilita un dispositivo de origen, la función coresight_find_activated_sysfs_sink se invoca recursivamente para intentar localizar un dispositivo receptor activo, lo que finalmente provoca un desbordamiento de pila y un bloqueo del sistema. Por lo tanto, deshabilite replicator1 para romper el bucle infinito y evitar un posible desbordamiento de pila. replicator1_out -> funnel_swao_in6 -> tmc_etf_swao_in -> tmc_etf_swao_out | | replicator1_in replicator_swao_in | | replicator0_out1 replicator_swao_out0 | | replicator0_in funnel_in1_in3 | | tmc_etf_out <- tmc_etf_in <- funnel_merg_out <- funnel_merg_in1 <- funnel_in1_out [rastreo de llamadas] dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 dump_stack+0x18/0x28 panic+0x340/0x3b0 nmi_panic+0x94/0xa0 panic_bad_stack+0x114/0x138 handle_bad_stack+0x34/0xb8 __bad_stack+0x78/0x80 coresight_find_activated_sysfs_sink+0x28/0xa0 [coresight] efecto secundario después del cambio: Solo los datos de seguimiento originados desde AOSS pueden alcanzar los receptores ETF_SWAO y EUD.