Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: Loongson64: DTS: Realmente arregla los nodos de puerto PCIe para ls7a Corrige las advertencias de dtc: arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Advertencia (interrupt_provider): /bus@10000000/pci@1a000000: Se encontró '#interrupt-cells', pero el nodo no es un proveedor de interrupciones arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Advertencia (interrupt_provider): /bus@10000000/pci@1a000000: Se encontró '#interrupt-cells', pero el nodo no es un proveedor de interrupciones arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Advertencia (interrupt_map): Error en el prerrequisito 'interrupt_provider' Y una advertencia de tiempo de ejecución introducida en el commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells management"): ADVERTENCIA: CPU: 0 PID: 1 en drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0 Falta '#address-cells' en /bus@10000000/pci@1a000000/pci_bridge@9,0 La solución es similar a el commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), que ha solucionado el problema para ls2k (a pesar de que su asunto menciona (ls7a).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: imx8m: Sondear el controlador SoC como controlador de plataforma Con driver_async_probe=* en la línea de comandos del kernel, se produce el siguiente seguimiento porque en el hardware i.MX8M Plus, el controlador soc-imx8m.c llama a of_clk_get_by_name(), que devuelve -EPROBE_DEFER porque el controlador de reloj aún no se ha sondeado. Esto no se detectó durante las pruebas regulares sin driver_async_probe. Convierta el código SoC en controlador de plataforma e instancie un dispositivo de plataforma en su device_initcall() actual para sondear el controlador de plataforma. Reelabore la devolución de llamada .soc_revision para que siempre devuelva un código de error válido y devuelva la revisión de SoC mediante un parámetro. De esta manera, si algo en la devolución de llamada .soc_revision devuelve -EPROBE_DEFER, se propaga a .probe y .probe se volverá a intentar más tarde. " ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 1 en drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180 CPU: 1 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.11.0-next-20240924-00002-g2062bb554dea #603 Nombre del hardware: Kit de desarrollador DH electronics i.MX8M Plus DHCOM Premium (3) (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : imx8mm_soc_revision+0xdc/0x180 lr : imx8mm_soc_revision+0xd0/0x180 sp : ffff8000821fbcc0 x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120 x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311 x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: ffffffffffffffffdfb x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffffff x17: x16: ffff8000823e1000 x15: ffff0000c03b65e8 x14: ffff0000c00051b0 x13: ffff800082790000 x12: 00000000000000801 x11: ffff80008278ffff x10: ffff80008209d3a6 x9: ffff80008062e95c x8: ffff8000821fb9a0 x7: 0000000000000000 x6: 00000000000080e3 x5: ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb Rastreo de llamadas: imx8mm_soc_revision+0xdc/0x180 imx8_soc_init+0xb0/0x1e0 do_one_initcall+0x94/0x1a8 kernel_init_freeable+0x240/0x2a8 kernel_init+0x28/0x140 ret_from_fork+0x10/0x20 ---[ fin del rastreo 000000000000000 ]--- SoC: i.MX8MP revisión 1.1 "

Un paquete 802.15.4 mal formado provoca un desbordamiento del búfer que da lugar a una confirmación y una denegación de servicio. Un restablecimiento del sistema de vigilancia elimina la condición de error automáticamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corregir la gestión del recuento de referencias del plano [Por qué] El mecanismo para realizar copias de seguridad y restaurar estados del plano no mantiene el recuento de referencias, lo que puede causar problemas si el recuento de referencias del plano cambia entre las operaciones de copia de seguridad y restauración, como fugas de memoria si se suponía que el recuento de referencias bajaría, o liberaciones dobles / accesos a memoria no válidos si se suponía que el recuento de referencias aumentaría. [Cómo] Almacenar en caché y volver a aplicar el recuento de referencias actual al restaurar estados del plano.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kunit: Se ha corregido una posible desreferencia nula en kunit_device_driver_test(). kunit_kzalloc() puede devolver un puntero NULL. Si se desreferencia sin una comprobación NULL, se puede generar una desreferencia NULL. Se ha añadido una comprobación NULL para test_state.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: añadir una comprobación de cordura para la raíz de btrfs en btrfs_search_slot() Syzbot informa de un null-ptr-deref en btrfs_search_slot(). El reproductor está usando rescue=ibadroots, y la raíz del árbol de extensiones está dañada, por lo que el árbol de extensiones es NULL. Cuando scrub intenta buscar en el árbol de extensiones para reunir la información de extensión necesaria, btrfs_search_slot() no comprueba si la raíz de destino es NULL o no, lo que da como resultado el null-ptr-deref. Añadir una comprobación de cordura para la raíz de btrfs antes de usarlo en btrfs_search_slot().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/sti: evitar la posible desreferencia de punteros de error. Es necesario comprobar el valor de retorno de drm_atomic_get_crtc_state() para evitar el uso del puntero de error 'crtc_state' en caso de fallo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/sti: evitar la posible desreferencia de punteros de error en sti_gdp_atomic_check Es necesario comprobar el valor de retorno de drm_atomic_get_crtc_state() para evitar el uso del puntero de error 'crtc_state' en caso de fallo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/sti: evitar la posible desreferencia de punteros de error en sti_hqvdp_atomic_check Es necesario comprobar el valor de retorno de drm_atomic_get_crtc_state() para evitar el uso del puntero de error 'crtc_state' en caso de fallo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: se corrige la pérdida de nfs4_openowner cuando se producen nfsd4_open concurrentes. La acción force umount(umount -f) intentará eliminar todas las rpc_task, aunque la operación umount puede fallar si algunos archivos permanecen abiertos. En consecuencia, si una acción intenta abrir un archivo, puede enviar dos rpc_task al servidor nfs. CLIENTE NFS thread1 thread2 open("archivo") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 se ha activado y ha devuelto -512 _nfs4_do_open // bucle while ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_task Mientras se procesa una solicitud de apertura, nfsd primero intentará encontrar o asignar un nfs4_openowner. Si encuentra un nfs4_openowner que no esté marcado como NFS4_OO_CONFIRMED, este nfs4_openowner se liberará. Dado que dos rpc_task pueden intentar abrir el mismo archivo simultáneamente desde el cliente al servidor, y debido a que dos instancias de nfsd pueden ejecutarse simultáneamente, esta situación puede provocar una gran pérdida de memoria. Además, cuando hacemos eco de 0 en /proc/fs/nfsd/threads, se activará una advertencia. SERVIDOR NFS nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // asignar oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // encontrar oo1, sin NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // no se puede encontrar este oo // del cliente, ¡FUGA! alloc_stateowner // asignar oo2 nfsd4_process_open2 init_open_stateid // asociar oo1 // con stateid1, stateid1 ¡FUGA! nfs4_get_vfs_file // asignar nfsd_file1 y nfsd_file_mark1 // ¡¡¡TODOS FUGAN!!! nfsd4_process_open2 ... subprocesos de escritura ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // ¡¡¡No encontrará oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy para nfsd_file_slab y nfsd_file_mark_slab // sin cambios desde nfsd_file1 // y nfsd_file_mark1 // siguen activos ============================================================================ ERROR nfsd_file (no contaminado): objetos que permanecen en nfsd_file en __kmem_cache_shutdown() ----------------------------------------------------------------------- Slab 0xffd4000004438a80 objetos=34 usados=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh No contaminado 6.12.0-rc6+ #19 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 01/04/2014 Seguimiento de llamadas: dum ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: quota: vaciar quota_release_work al reescribir la cuota Una de las rutas desde las que se llama a la reescritura de cuota es: freeze_super() sync_filesystem() ext4_sync_fs() dquot_writeback_dquots() Dado que actualmente no siempre vaciamos la cola quota_release_work en esta ruta, podemos terminar con la siguiente ejecución: 1. dquot se agregan a la lista release_dquots durante las operaciones regulares. 2. FS Freeze comienza, sin embargo, esto no vacía la cola quota_release_work. 3. Freeze se completa. 4. El kernel finalmente intenta vaciar la cola de trabajo mientras FS está congelado, lo que genera un WARN_ON ya que la transacción se inicia durante el estado congelado: ext4_journal_check_start+0x28/0x110 [ext4] (no confiable) __ext4_journal_start_sb+0x64/0x1c0 [ext4] ext4_release_dquot+0x90/0x1d0 [ext4] quota_release_workfn+0x43c/0x4d0 Que es la siguiente línea: WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE); Lo que finalmente da como resultado que generic/390 falle debido al ruido de dmesg. Esto se detectó en una máquina PowerPC de 15 núcleos. Para evitar esto, asegúrese de vaciar la cola de trabajo durante dquot_writeback_dquots() para que no tengamos ningún elemento de trabajo pendiente después del congelamiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: spinand: winbond: Corrige la información ECC de 512GW, 01GW, 01JW y 02JW Estos cuatro chips: * W25N512GW * W25N01GW * W25N01JW * W25N02JW requieren un solo bit de fuerza ECC y, por lo tanto, cuentan con un motor ECC tipo Hamming en la matriz. No tiene sentido completar una devolución de llamada ->get_status() para ellos porque los bytes de estado ECC principales se encuentran en lugares estándar, y recuperar el número de bitflips en caso de un fragmento corregido es inútil y no tiene soporte (si hay bitflips, entonces hay 1 como máximo, por lo que no es necesario consultar al chip para eso). Sin este cambio, se activa una advertencia del kernel cada vez que se cambia un bit.