Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: Se corrigen posibles accesos fuera de los límites para dispositivos Extigy y Mbox Un dispositivo falso puede proporcionar un valor bNumConfigurations que exceda el valor inicial utilizado en usb_get_configuration para asignar dev->config. Esto puede provocar accesos fuera de los límites más adelante, por ejemplo, en usb_destroy_configuration.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el problema de use-after-free en la gestión de solicitudes SMB Existe una condición de ejecución entre la gestión de solicitudes SMB en `ksmbd_conn_handler_loop()` y la liberación de `ksmbd_conn` en el controlador de cola de trabajo `handle_ksmbd_work()`. Esto conduce a una UAF. - KASAN: slab-use-after-free Leer en handle_ksmbd_work - KASAN: slab-use-after-free en rtlock_slowlock_locked Esta condición de ejecución surge de la siguiente manera: - `ksmbd_conn_handler_loop()` espera a que `conn->r_count` llegue a cero: `wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);` - Mientras tanto, `handle_ksmbd_work()` decrementa `conn->r_count` usando `atomic_dec_return(&conn->r_count)`, y si llega a cero, llama a `ksmbd_conn_free()`, que libera a `conn`. - Sin embargo, después de que `handle_ksmbd_work()` disminuya `conn->r_count`, aún puede acceder a `conn->r_count_q` en la siguiente línea: `waitqueue_active(&conn->r_count_q)` o `wake_up(&conn->r_count_q)` Esto da como resultado un UAF, ya que `conn` ya se ha liberado. Se puede hacer referencia al descubrimiento de este UAF en la siguiente PR para el soporte de syzkaller para solicitudes SMB.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: comprobar si hay desbordamientos en io_pin_pages ADVERTENCIA: CPU: 0 PID: 5834 en io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 No contaminado 6.12.0-next-20241118-syzkaller #0 Seguimiento de llamadas: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [en línea] El parámetro uaddr de io_pin_pages() proviene directamente del usuario y puede ser basura. No le agregue tamaño, ya que puede desbordarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: se corrige el fallo al desvincular Si hay un error durante alguna inicialización relacionada con el firmware, se llama a la función ath12k_dp_cc_cleanup para liberar recursos. Sin embargo, esto se libera de nuevo cuando se desvincula el dispositivo (ath12k_pci), y obtenemos: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000020 en RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k] Seguimiento de llamadas: ath12k_dp_cc_cleanup ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... El problema siempre se puede reproducir desde una máquina virtual porque la inicialización del direccionamiento MSI está fallando. Para solucionar el problema, simplemente establezca en NULL la estructura liberada en ath12k_dp_cc_cleanup al final.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan La matriz channels en cfg80211_scan_request tiene un atributo __counted_by adjunto, que apunta a la variable n_channels. Este atributo se utiliza en la comprobación de los límites y, si no se configura antes de que se complete la matriz, el desinfectante de los límites emitirá una advertencia o un pánico del kernel si se configura CONFIG_UBSAN_TRAP. Este parche establece el tamaño de la memoria asignada como el valor inicial para n_channels. Se actualiza con el número real de elementos agregados después de que se complete la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corregir advertencia al desvincular Si hay un error durante alguna inicialización relacionada con el firmware, se liberan los búferes dp->tx_ring[i].tx_status. Sin embargo, esto se libera nuevamente cuando se desvincula el dispositivo (ath12k_pci), y obtenemos: ADVERTENCIA: CPU: 0 PID: 2098 en mm/slub.c:4689 free_large_kmalloc+0x4d/0x80 Rastreo de llamadas: free_large_kmalloc ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... El problema siempre se puede reproducir desde una VM porque la inicialización de la dirección MSI está fallando. Para solucionar el problema, simplemente configure los búferes en NULL después de liberar para evitar la doble liberación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: clk-loongson2: Se corrige un desbordamiento de búfer potencial en el acceso a miembros de la matriz flexible El miembro de la matriz flexible `hws` en `struct clk_hw_onecell_data` está anotado con el atributo `counted_by()`. Esto significa que cuando se asigna memoria para esta matriz, el _contador_, que en este caso es el miembro `num` en la estructura flexible, se debe establecer en el número máximo de elementos que la matriz flexible puede contener, o menos. En este caso, el número total de elementos para la matriz flexible se determina mediante la variable `clks_num` al asignar espacio de montón a través de `devm_kzalloc()`, como se muestra a continuación: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); Por lo tanto, `clp->clk_data.num` debe establecerse en `clks_num` o menos, y no superar `clks_num`, como es el caso actualmente. De lo contrario, si los datos se escriben en `clp->clk_data.hws[clks_num]`, la instrumentación proporcionada por el compilador no detectará el desbordamiento, lo que provocará un error de corrupción de memoria en tiempo de ejecución. Solucione este problema estableciendo `clp->clk_data.num` en `clks_num`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: clk-loongson2: Se corrige un error de corrupción de memoria en struct loongson2_clk_provider. Se asigna algo de espacio de montón para la estructura flexible `struct clk_hw_onecell_data` y su miembro de matriz flexible `hws` a través de la estructura compuesta `struct loongson2_clk_provider` en la función `loongson2_clk_probe()`, como se muestra a continuación: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); Luego, se escriben algunos datos en la matriz flexible: 350 clp->clk_data.hws[p->id] = hw; Esto corrompe `clk_lock`, que es la variable spinlock que sigue inmediatamente al miembro `clk_data` en `struct loongson2_clk_provider`: struct loongson2_clk_provider { void __iomem *base; struct device *dev; struct clk_hw_onecell_data clk_data; spinlock_t clk_lock; /* proteger el acceso a los registros DIV */ }; El problema es que la estructura flexible actualmente está ubicada en el medio de `struct loongson2_clk_provider` en lugar de al final. Solucione esto moviendo `struct clk_hw_onecell_data clk_data;` al final de `struct loongson2_clk_provider`. Además, agregue un comentario de código para ayudar a evitar que esto vuelva a suceder en caso de que se agreguen nuevos miembros a la estructura en el futuro. Este cambio también corrige la siguiente advertencia -Wflex-array-member-not-at-end: drivers/clk/clk-loongson2.c:32:36: advertencia: la estructura que contiene un miembro de matriz flexible no está al final de otra estructura [-Wflex-array-member-not-at-end]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtlwifi: Reduce drásticamente los intentos de leer efuse en caso de fallos Syzkaller informó de una tarea colgada con uevent_show() en el seguimiento de la pila. Ese problema específico fue abordado por otra confirmación [0], pero incluso con esa corrección aplicada (por ejemplo, ejecutando v6.12-rc5) nos enfrentamos a otro tipo de tarea colgada que proviene del mismo reproductor [1]. Al investigar eso, pudimos reducirlo a la siguiente ruta: (a) Syzkaller emula un adaptador WiFi USB Realtek utilizando raw-gadget y la infraestructura dummy_hcd. (b) Durante el sondeo de rtl8192cu, el controlador termina realizando un procedimiento de lectura de efuse (que está relacionado con la carga de EEPROM IIUC), y aquí radica el problema: la función read_efuse() llama a read_efuse_byte() muchas veces, como iteraciones de bucle dependiendo del tamaño de efuse (en nuestro ejemplo, 512 en total). Este procedimiento para leer bytes de efuse se basa en un bucle que realiza una lectura de E/S hasta *10k* veces en caso de fallas. Medimos el tiempo del bucle dentro de read_efuse_byte() solamente, y en este reproductor (que involucra la capa de emulación dummy_hcd), toma 15 segundos cada uno. Como consecuencia, tenemos al controlador atascado en su rutina de sondeo por mucho tiempo, exponiendo un seguimiento de pila como el siguiente si intentamos reiniciar el sistema, por ejemplo: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 lectura_efuse_byte+0x13c/0x146 lectura_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] Proponemos reducir drásticamente los intentos de realizar lecturas de E/S en caso de fallos, restringidos a dispositivos USB (dado que son inherentemente más lentos que los PCIe). Al reintentar hasta 10 veces (en lugar de 10000), obtuvimos capacidad de respuesta en el reproductor, aunque parece razonable creer que no existe una implementación sensata de dispositivos USB en el campo que requiera esta cantidad de reintentos en cada lectura de E/S para funcionar correctamente. En base a esa suposición, sería bueno tenerlo retroportado a estable, pero tal vez no desde la implementación del controlador (el número 10k proviene del día 0), tal vez hasta la serie 6.x tenga sentido. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") [1] Una nota sobre eso: este informe de syzkaller presenta múltiples reproductores que difieren según el tipo de dispositivo USB emulado. Para este caso específico, verifique la entrada de 2024/08/08 06:23 en la lista de fallas; la reproducción en C está disponible en https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: evitar el use-after-free debido a las rutas de error de open_cached_dir Si open_cached_dir() encuentra un error al analizar el arrendamiento desde el servidor, la gestión de errores puede acelerarse con la recepción de una interrupción del arrendamiento, lo que da como resultado que open_cached_dir() libere el cfid mientras el trabajo en cola está pendiente. Actualice open_cached_dir() para eliminar referencias en lugar de liberar directamente el cfid. Haga que cached_dir_lease_break(), cfids_laundromat_worker() e invalidate_all_cached_dirs() borren has_lease inmediatamente mientras aún mantienen cfids->cfid_list_lock, y luego use esto para simplificar también el conteo de referencias en cfids_laundromat_worker() e invalidate_all_cached_dirs(). Corrige este problema de KASAN (que inyecta manualmente un error y una interrupción de arrendamiento en open_cached_dir()): ====================================================================== ERROR: KASAN: slab-use-after-free en smb2_cached_lease_break+0x27/0xb0 Lectura de tamaño 8 en la dirección ffff88811cc24c10 por la tarea kworker/3:1/65 CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 No contaminado 6.12.0-rc6-g255cf264e6e5-dirty #87 Nombre del hardware: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/11/2020 Cola de trabajo: cifsiod smb2_cached_lease_break Seguimiento de llamadas: dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Asignado por la tarea 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 directorio_caché_abierto+0xa7d/0x1fb0 información_ruta_consulta_smb2+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 información_inodo_obtener_cifs+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 ruta_statx_vfs+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Última creación de trabajo potencialmente relacionado: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 cola_trabajo_activada+0x82/0x90 directorio_caché_abierto+0x1369/0x1fb0 información_ruta_consulta_smb2+0x43c/0x6e0 cifs_obtener_fattr+0x346/0xf10 cifs_obtener_información_inodo+0x157/0x210 cifs_revalidar_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 ruta_statx_vfs+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e La dirección con errores pertenece al objeto en ffff88811cc24c00 que pertenece al caché kmalloc-1k de tamaño 1024 La dirección con errores se encuentra 16 bytes dentro de la región liberada de 1024 bytes [ffff88811cc24c00, ffff88811cc25000)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: No filtrar cfid cuando la reconexión compite con open_cached_dir open_cached_dir() puede competir con la reconexión tcon incluso antes de Compound_send_recv() o activar directamente una reconexión a través de SMB2_open_init() o SMB_query_info_init(). El proceso de reconexión invoca invalidate_all_cached_dirs() a través de cifs_mark_open_files_invalid(), que elimina todos los cfids de la lista cfids->entries pero no elimina una referencia si has_lease no es verdadero. Esto da como resultado que el cfid que se está construyendo actualmente no esté en la lista, pero aún tenga un recuento de referencias de 2. Se filtra si se devuelve desde open_cached_dir(). Solucione esto configurando cfid->has_lease cuando la referencia se toma realmente; el cfid no será utilizado por otros subprocesos hasta que tenga un tiempo válido. Aborda estos kmemleaks: objeto sin referencia 0xffff8881090c4000 (tamaño 1024): comm "bash", pid 1860, jiffies 4295126592 volcado hexadecimal (primeros 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de .........."....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"...O..... backtrace (crc 6f58c20f): [] __kmalloc_cache_noprof+0x2be/0x350 [] directorio_caché_abierto+0x993/0x1fb0 [] directorio_lectura_cifs+0x15a0/0x1d50 [] directorio_iteración+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] llamada_al_sistema_64+0x95/0x1a0 [] entrada_SYSCALL_64_después_de_hwframe+0x76/0x7e objeto sin referencia 0xffff8881044fdcf8 (tamaño 8): comm "bash", pid 1860, jiffies 4295126592 volcado hexadecimal (primeros 8 bytes): 00 cc cc cc cc cc cc cc cc ........ seguimiento inverso (crc 10c106a9): [] __kmalloc_node_track_caller_noprof+0x363/0x480 [] kstrdup+0x36/0x60 [] open_cached_dir+0x9b0/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e Y soluciona estos errores al desmontar el sistema de archivos SMB: ERROR: Dentry ffff888140590ba0{i=1000000000080,n=/} todavía en uso (2) [desmontaje de cifs cifs] ADVERTENCIA: CPU: 3 PID: 3433 en fs/dcache.c:1536 umount_check+0xd0/0x100 Módulos vinculados: CPU: 3 UID: 0 PID: 3433 Comm: bash No contaminado 6.12.0-rc4-g850925a8133c-dirty #49 Nombre del hardware: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/11/2020 RIP: 0010:umount_check+0xd0/0x100 Código: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41 RSP: 0018:ffff88811cc27978 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: fffffffaaf20bae RDX: dffffc0000000000 RSI: 00000000000000008 RDI: ffff8881f6fb6f40 RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3 R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08 R13: 00000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0 FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0 Seguimiento de llamadas: d_walk+0x6a/0x530 encoger_dcache_for_umount+0x6a/0x200 apagado_genérico_super+0x52/0x2a0 matar_anónimo_super+0x22/0x40 matar_sb_cifs+0x159/0x1e0 desactivar_bloqueado_super+0x66/0xe0 desinfección_mnt+0x140/0x210 ejecución_trabajo_tarea+0xfb/0x170 salida_llamada_al_sistema_al_modo_usuario+0x29f/0x2b0 llamada_al_sistema_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f23bfb93ae7 Código: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige el use-after-free de la clave de firma Los clientes han informado sobre el use-after-free en @ses->auth_key.response con SMB2.1 + montajes de firma que se producen debido a la siguiente ejecución: tarea A tarea B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() Compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF* Solucione esto asegurándose de que tenemos un @ses->auth_key.response válido comprobando si @ses->ses_status es SES_GOOD o SES_EXITING con @ses->ses_lock Después de el commit 24a9799aa8ef ("smb: cliente: corregir UAF en smb2_reconnect_server()"), nos aseguramos de llamar a ->logoff() solo cuando se sabía que @ses era correcto (por ejemplo, ->auth_key.response válido), por lo que es seguro acceder a la clave de firma cuando @ses->ses_status == SES_EXITING.