Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb: client: corrige use-after-free en smb2_query_info_compound(). El siguiente UAF se activó al ejecutar fstests generic/072 con KASAN habilitado en Windows Server 2022 y opciones de montaje 'multicanal, max_channels=2,vers=3.1.1,mfsymlinks,noperm' BUG: KASAN: slab-use-after-free en smb2_query_info_compound+0x423/0x6d0 [cifs] Lectura de tamaño 8 en la dirección ffff888014941048 por tarea xfs_io/27534 CPU: 0 PID : 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 01/04/2014 Llamada Seguimiento: dump_stack_lvl+0x4a/0x80 print_report+0xcf/0x650 ? srso_alias_return_thunk+0x5/0x7f? srso_alias_return_thunk+0x5/0x7f? __phys_addr+0x46/0x90 kasan_report+0xda/0x110 ? smb2_query_info_compound+0x423/0x6d0 [cifs]? smb2_query_info_compound+0x423/0x6d0 [cifs] smb2_query_info_compound+0x423/0x6d0 [cifs] ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f? __stack_depot_save+0x39/0x480? kasan_save_stack+0x33/0x60? kasan_set_track+0x25/0x30? ____kasan_slab_free+0x126/0x170 smb2_queryfs+0xc2/0x2c0 [cifs] ? __pfx_smb2_queryfs+0x10/0x10 [cifs] ? __pfx___lock_acquire+0x10/0x10 smb311_queryfs+0x210/0x220 [cifs]? __pfx_smb311_queryfs+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f? __lock_acquire+0x480/0x26c0? lock_release+0x1ed/0x640? srso_alias_return_thunk+0x5/0x7f? do_raw_spin_unlock+0x9b/0x100 cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 ? __pfx___do_sys_fstatfs+0x10/0x10 ? srso_alias_return_thunk+0x5/0x7f? lockdep_hardirqs_on_prepare+0x136/0x200? srso_alias_return_thunk+0x5/0x7f do_syscall_64+0x3f/0x90 Entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Asignado por tarea 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f /0xa0 open_cached_dir+0x71b/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs ] smb2_queryfs+0xc2/0x2c0 [cifs] smb311_queryfs+0x210/0x220 [cifs] cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 statfs+0x7f/0xe0 do_syscall_64+0x3f/0x90 entrada_SYSCALL_64_after_hwframe+0x6e/0xd8 Liberado por la tarea 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 ____kasan_slab_free+0x126/0x170 slab_free_freelist_hook+0xd0/0x1e0 __kmem_cache_free+0x9d/0x 1b0 open_cached_dir+0xff5/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs ] smb2_queryfs+0xc2/0x2c0 [cifs] Esta es una ejecución entre open_cached_dir() y cached_dir_lease_break() donde la entrada de caché para el identificador de directorio abierto recibe una interrupción de arrendamiento mientras se crea. Y antes de volver de open_cached_dir(), ponemos la última referencia del nuevo @cfid por !@cfid->has_lease. Además de UAF, al ejecutar xfstests se han observado muchas interrupciones de arrendamiento perdidas en pruebas que ejecutan varias llamadas statfs(2) simultáneas en esos fids almacenados en caché CIFS: VFS: \\w22-root1.gandalf.test No hay tarea para activar, desconocida marco... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Banderas: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108 CIFS: VFS : Volcado de solicitudes pendientes: CIFS: VFS: \\w22-root1.gandalf.test No hay tarea para activar, marco desconocido... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Banderas: 0x1 ... CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108 ... Para arreglar ambos, en open_cached_dir() asegúrese de que @cfid->has_lease esté configurado justo antes de enviar una solicitud compuesta para que cualquier La posible interrupción del arrendamiento será procesada por el subproceso demultiplex mientras todavía estamos almacenando en caché @cfid. Y, si la apertura falla por algún motivo, vuelva a verificar @cfid->has_lease para decidir si coloca o no la referencia del arrendamiento.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: Evite la desreferencia NULL del generador de temporización [Por qué y cómo] Verifique si el generador de temporización asignado es NULL o no antes de acceder a sus funciones para evitar la desreferencia NULL.

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.