Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: imon: corrige el acceso a un recurso no válido para la segunda interfaz. El controlador imon prueba dos interfaces USB y, en la prueba de la segunda interfaz, el controlador asume ciegamente que la primera interfaz obtuvo atado con el mismo conductor imon. Generalmente es cierto, pero aún es posible que la primera interfaz esté vinculada con otro controlador a través de un descriptor con formato incorrecto. Entonces puede provocar una corrupción de la memoria, como descubrió syzkaller; El controlador imon accede a los datos de drvdata como objeto struct imon_context aunque es uno completamente diferente asignado por otro controlador. Este parche agrega una verificación de cordura (si la primera interfaz está realmente vinculada con el controlador imon o no) para evitar el problema anterior en el momento de la prueba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corrige el error de use after free en cifs_debug_data_proc_show(). Omitir sesiones SMB que se están eliminando (por ejemplo, @ses->ses_status == SES_EXITING) en cifs_debug_data_proc_show() para evitar el use after free en @ses. Esto corrige el siguiente GPF al leer desde /proc/fs/cifs/DebugData mientras se monta y desmonta [816.251274] falla de protección general, probablemente para la dirección no canónica 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI... [816.260138] Llamada Seguimiento: [816.260329] [816.260499] ? die_addr+0x36/0x90 [816.260762]? exc_general_protection+0x1b3/0x410 [816.261126]? asm_exc_general_protection+0x26/0x30 [816.261502]? cifs_debug_tcon+0xbd/0x240 [cifs] [816.261878]? cifs_debug_tcon+0xab/0x240 [cifs] [816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs] [816.262689]? seq_read_iter+0x379/0x470 [816.262995] seq_read_iter+0x118/0x470 [816.263291] proc_reg_read_iter+0x53/0x90 [816.263596] ? srso_alias_return_thunk+0x5/0x7f [ 816.263945] vfs_read+0x201/0x350 [ 816.264211] ksys_read+0x75/0x100 [ 816.264472] do_syscall_64+0x3f/0x90 [ 816.2647 50] entrada_SYSCALL_64_after_hwframe+0x6e/0xd8 [816.265135] RIP: 0033:0x7fd5e669d381

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: mmc_spi: corrige el manejo de errores en mmc_spi_probe(). Si mmc_add_host() falla, no es necesario llamar a mmc_remove_host(), o causará null-ptr-deref, debido a la eliminación de un dispositivo no agregado en mmc_remove_host(). Para solucionar este problema, vaya a la etiqueta 'fail_glue_init', si mmc_add_host() falla, y cambie la etiqueta 'fail_add_host' a 'fail_gpiod_request'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: sdio: soluciona posibles fugas de recursos en algunas rutas de error. Si sdio_add_func() o sdio_init_func() falla, sdio_remove_func() no puede liberar los recursos, porque no se presenta la función sdio en estos dos casos, no llamará a of_node_put() o put_device(). Para solucionar estas fugas, haga que sdio_func_present() solo controle si es necesario llamar a device_del() o no, luego llame siempre a of_node_put() y put_device(). En caso de error en sdio_init_func(), la referencia de 'card->dev' no se obtiene, para evitar la colocación redundante en sdio_free_func_cis(), mueva get_device() a sdio_alloc_func() y put_device() a sdio_release_func(), puede mantenga equilibrada la función get/put. Sin este parche, mientras realiza la prueba de inyección de fallas, puede obtener los siguientes informes de fugas; después de esta solución, la fuga desaparece. objeto sin referencia 0xffff888112514000 (tamaño 2048): comunicación "kworker/3:2", pid 65, jiffies 4294741614 (edad 124,774 s) volcado hexadecimal (primeros 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 8 y siguientes ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... retroceso : [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] objeto sin referencia 0xffff888112511000 (tamaño 2048): comm "kworker/3:2", pid 65, santiamén 4294741623 (edad 124,766 s) volcado hexadecimal (primero 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q. ......P..... rastreo inverso: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold. 18+0xb1/ 0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: corrige el acceso a páginas no válidas después de cerrar dispositivos de E/S diferidas. Cuando un fbdev con E/S diferidas se abre y cierra una vez, las páginas sucias aún permanecen en cola en la lista pageref. y, eventualmente, más adelante, podrán procesarse en el trabajo retrasado. Esto puede provocar la corrupción de las páginas y provocar un error. Este parche garantiza cancelar el trabajo retrasado y limpiar la lista de referencias de página al cerrar el dispositivo para solucionar el error. Una parte del código de limpieza se factoriza como una nueva función auxiliar que se llama desde el fb_release() común.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: lista de bloqueo del kclient cuando se recibe un seguimiento instantáneo corrupto. Cuando recibimos un seguimiento instantáneo corrupto, no sabemos qué ha sucedido exactamente en el lado MDS. Y no debemos continuar con el acceso de IO y metadatos a MDS, lo que puede dañar u obtener contenidos incorrectos. Este parche simplemente bloqueará todas las solicitudes IO/MDS adicionales inmediatamente y luego expulsará al propio kclient. La razón por la que todavía necesitamos desalojar al kclient justo después de bloquear todas las IO adicionales es que el MDS podría revocar los límites más rápido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/decompressor: especifique __decompress() buf len para evitar el desbordamiento. Históricamente, las llamadas a __decompress() no especificaban el parámetro "out_len" en muchas arquitecturas, incluido s390, esperando que no se escribieran más allá Se realizan imágenes del kernel sin comprimir. Esto ha cambiado desde la confirmación 2aa14b1ab2c4 ("zstd: import usptream v1.5.2") que incluye la confirmación de la biblioteca zstd 6a7ede3dfccb ("Reducir el tamaño de dctx reutilizando el búfer dst (#2751)"). Ahora el código de descompresión zstd podría almacenar un búfer literal en la parte no escrita del búfer de destino. Dado que "out_len" no está configurado, se considera ilimitado y, por lo tanto, de uso gratuito para las necesidades de optimización. En s390, esto podría dañar el informe initrd o ipl que a menudo se coloca justo después del buffer del descompresor. Afortunadamente, el descompresor ya conoce el tamaño de la imagen del kernel sin comprimir, por lo que para evitar el problema simplemente especifíquelo en el parámetro "out_len".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: sch: Prioridad de verificación de límites. Nada estaba explícitamente limitado al verificar el índice de prioridad utilizado para acceder a clpriop[]. AVISO y salga temprano si es patológico. Visto con GCC 13: ../net/sched/sch_htb.c: En función 'htb_activate_prios': ../net/sched/sch_htb.c:437:44: advertencia: el subíndice de matriz [0, 31] está fuera de los límites de la matriz de 'struct htb_prio[8]' [-Warray-bounds=] 437 | si (p->inner.clprio[prio].feed.rb_node) | ~~~~~~~~~~~~~~~^~~~~~ ../net/sched/sch_htb.c:131:41: nota: al hacer referencia a 'clprio' 131 | estructura htb_prio clprio[TC_HTB_NUMPRIO]; | ^~~~~~

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: no permita que sock_map_{close,destroy,unhash} se llame a sí mismo. Las devoluciones de llamada del proto sock_map nunca deberían llamarse a sí mismas por diseño. Protéjase contra bugs como [1] y salga del bucle recursivo para evitar un desbordamiento de la pila que favorezca una fuga de recursos. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: no desarmar el valor predeterminado al limpiar el códec. Varias funciones que participan en la inicialización y eliminación del códec son reutilizadas por las implementaciones de controladores de códec ASoC. Los controladores imitan el comportamiento de hda_codec_driver_probe/remove() que se encuentra en sound/pci/hda/hda_bind.c con su componente->probe/remove(). Una de las razones de esto es la expectativa de que snd_hda_codec_device_new() reciba un puntero válido a una instancia de struct snd_card. Esta expectativa sólo podrá cumplirse una vez que comience la investigación de los componentes de la tarjeta de sonido. Como la tarjeta de sonido ASoC puede desconectarse sin que el dispositivo códec se elimine realmente del sistema, desarmar ->preset en snd_hda_codec_cleanup_for_unbind() interfiere con la descarga del módulo -> escenario de carga causando null-ptr-deref. El ajuste preestablecido se asigna solo una vez, durante la coincidencia de dispositivo/controlador, mientras que la recarga del módulo del controlador del códec ASoC puede ocurrir varias veces durante la vida útil de una pila de audio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: bloquea el inodo en modo compartido antes de iniciar fiemap. Actualmente, fiemap no toma el bloqueo del inodo (bloqueo VFS), solo bloquea un rango de archivos en el árbol io del inodo. Sin embargo, esto puede llevar a un punto muerto si tenemos un fsync simultáneo en el archivo y el código fiemap desencadena una falla al acceder al búfer de espacio de usuario con fiemap_fill_next_extent(). El punto muerto ocurre en el semáforo i_mmap_lock del inodo, que es tomado tanto por fsync como por btrfs_page_mkwrite(). Syzbot informó recientemente de este punto muerto y activa un seguimiento como el siguiente: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c: 5293 [en línea] __schedule+0x995/0xe20 kernel/sched/core.c:6606 Schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [en línea] wait_extent_bit +0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc +0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extensión_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extensión_writepages+0x219/0 x540 fs/btrfs/ extend_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [en línea] filemap_fdatawrite_range+0x175/0x200 mm/filemap .c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [en línea] start_ordered_ops fs/btrfs/file.c:1737 [en línea] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs .h:2885 [en línea] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [en línea] new_sync_write fs/read_write.c:491 [en línea] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 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 RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: fffffffffffffda 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFORMACIÓN: tarea syz-executor361:5697 bloqueada durante más de 145 segundos. No contaminado 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:syz-executor361 estado:D pila:21216 pid:5697 ppid:5119 banderas:0x00004004 Seguimiento de llamadas: context_switch kernel/sched/core.c:5293 [en línea] __schedule+0x995/0xe20 kernel/sched/core. c:6606 Schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/ 0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [en línea] __handle_mm_fault mm/memory.c :5073 [en línea] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [en línea] exc_page_fault+ 0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S :233 Código: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu/fence: se solucionó el error debido a que drm_sched init/fini no coincide. Actualmente, amdgpu llama a drm_sched_fini() desde la rutina SW fini del controlador de valla; se espera que se llame a dicha función. sólo después de que la función de inicio respectiva, drm_sched_init(), se haya ejecutado correctamente. Sucede que recientemente nos enfrentamos a una falla en la sonda del controlador en Steam Deck, y se llamó a la función drm_sched_fini() incluso sin que su contraparte se hubiera llamado previamente, lo que provocó el siguiente error: amdgpu: la sonda de 0000:04:00.0 falló con error -110 ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000090 PGD 0 P4D 0 Ups: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd No contaminado 6.2.0-rc3-gpiccoli #338 Nombre del hardware : Valve Jupiter/Jupiter, BIOS F7A0113 04/11/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Seguimiento de llamadas: amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [ amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] Para evitar eso, verifique si drm_sched se inicializó correctamente para un anillo determinado antes de llamar a su contraparte fini. Observe que idealmente usaríamos sched.ready para eso; dicho campo se establece como lo último en drm_sched_init(). Pero amdgpu parece "sobreescribir" el significado de dicho campo; en el ejemplo anterior, por ejemplo, fue un anillo GFX el que provocó el bloqueo y el campo sched.ready se configuró en verdadero en la rutina de inicio del anillo, independientemente del estado de el programador DRM. Por lo tanto, terminamos usando sched.ops según la sugerencia de Christian [0] y también eliminamos la verificación no_scheduler [1]. [0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/ [1] https://lore.kernel.org/amd-gfx/cd0e2994- f85f-d837-609f-7056d5fb7231@amd.com/