Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: hyperv: optimizar la sonda del controlador para evitar problemas con devres Se encontró que descargar el módulo 'hid_hyperv' da como resultado una queja de devres: ... hv_vmbus: anulando el registro del controlador hid_hyperv ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 3983 en drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Seguimiento de llamadas: ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? grupo_liberación_devres+0x1f2/0x2c0 ? grupo_liberación_devres+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_grupo_liberación_devres+0x10/0x10 eliminación_dispositivo_hid+0xf5/0x220 controlador_liberación_dispositivo_interno+0x371/0x540 ? klist_put+0xf3/0x170 eliminación_dispositivo_bus+0x1f1/0x3f0 dispositivo_del+0x33f/0x8c0 ? __pfx_dispositivo_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ... Y el problema parece ser que el grupo devres correspondiente no está asignado. Normalmente, devres_open_group() se llama desde __hid_device_probe() pero el controlador HID de Hyper-V anula 'hid_dev->driver' con el stub 'mousevsc_hid_driver' y básicamente vuelve a implementar __hid_device_probe() llamando a hid_parse() y hid_hw_start() pero no a devres_open_group(). hid_device_probe() no llama a __hid_device_probe() para ello. Más tarde, cuando se elimina el controlador, hid_device_remove() llama a devres_release_group() ya que no verifica si hdev->driver se anuló inicialmente o no. El problema parece estar relacionado con el commit 62c68e7cee33 ("HID: garantizar la liberación oportuna de los recursos asignados al controlador") pero el commit en sí parece ser correcta. Solucione el problema eliminando la anulación de 'hid_dev->driver' y utilizando hid_register_driver()/hid_unregister_driver() en su lugar. Como alternativa, habría sido posible confiar en la gestión predeterminado, pero HID_CONNECT_DEFAULT implica HID_CONNECT_HIDRAW y no parece funcionar para mousevsc tal como está.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: soc: xilinx: agregue el kfree faltante en xlnx_add_cb_for_suspend() Si no podemos asignar memoria para cb_data mediante kmalloc, la asignación de memoria para eve_data nunca se libera, agregue el kfree() faltante en la ruta de gestión de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu/nocb: Corregir la barrera RCU omitida al descargar Actualmente, ejecutar la prueba rcutorture con torture_type=rcu fwd_progress=8 n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60 test_boost=2, activará la siguiente advertencia: ADVERTENCIA: CPU: 19 PID: 100 en kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0 RIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0 Rastreo de llamadas: ? __warn+0x7e/0x120 ? rcu_nocb_rdp_deoffload+0x292/0x2a0? report_bug+0x18e/0x1a0? handle_bug+0x3d/0x70? exc_invalid_op+0x18/0x70? asm_exc_invalid_op+0x1a/0x20? rcu_nocb_rdp_deoffload+0x292/0x2a0 rcu_nocb_cpu_deoffload+0x70/0xa0 rcu_nocb_toggle+0x136/0x1c0? __pfx_rcu_nocb_toggle+0x10/0x10 kthread+0xd1/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 CPU0 CPU2 CPU3 //rcu_nocb_toggle //nocb_cb_wait //rcutorture // desconecta la CPU1 // procesa el rdp de la CPU1 rcu_barrier() rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 2 // poner en cola la barrera // devolución de llamada a rdp->cblist de CPU1 rcu_do_batch() // invocar rdp->cblist de CPU1 // devolución de llamada rcu_barrier_callback() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // todavía se ve len == 2 // poner en cola la barrera // devolución de llamada a rdp->cblist de CPU1 rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 3 // decrementar len rcu_segcblist_add_len(-2); kthread_parkme() // rdp->cblist de CPU1 len == 1 // Advertir porque todavía hay una barrera pendiente // activar la advertencia WARN_ON_ONCE(rcu_segcblist_n_cbs(&rdp->cblist)); cpus_read_unlock(); // esperar a que la CPU1 se conecte e // invocar la devolución de llamada de barrera en // la CPU1 rdp's->cblist wait_for_completion(&rcu_state.barrier_completion); // descargar la CPU4 cpus_read_lock() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // bloquear en barrier_mutex // esperar a que rcu_barrier() en // la CPU3 desbloquee barrier_mutex // pero la CPU3 desbloquea barrier_mutex // necesita esperar a que la CPU1 se conecte // cuando la CPU1 se conecte se bloqueará en cpus_write_lock El escenario anterior no solo activará un WARN_ON_ONCE(), sino que también activará un bloqueo. Gracias al bloqueo de nocb, un segundo rcu_barrier() en una CPU fuera de línea observará el contador de devolución de llamadas reducido a 0 y ahorrará la puesta en cola de devolución de llamadas, o rcuo observará la nueva devolución de llamada y mantendrá rdp->nocb_cb_sleep en falso. Por lo tanto, verifique rdp->nocb_cb_sleep antes de estacionar para asegurarse de que no haya más rcu_barrier() esperando en el rdp.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: Arreglar la desreferencia de puntero NULL en object->file En la actualidad, object->file tiene el problema de desreferencia de puntero NULL en el modo ondemand. La causa raíz es que el fd asignado y el tiempo de vida de object->file son inconsistentes, y la invocación del espacio de usuario a anon_fd usa object->file. A continuación, se muestra el proceso que desencadena el problema: [write fd] [umount] cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file ¡Desreferencia de puntero NULL! __cachefiles_write(..., file, ...) Solucione este problema agregando un recuento de referencia adicional al objeto->archivo antes de escribir/llseek, y disminuya después de que finalice.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hfsplus: no consultar el tamaño del bloque lógico del dispositivo varias veces Los tamaños de bloque de los dispositivos pueden cambiar. Uno de estos casos es un dispositivo de bucle mediante el uso de ioctl LOOP_SET_BLOCK_SIZE. Si bien esto puede causar otros problemas como el rechazo de IO, en el caso de hfsplus, asignará un bloque utilizando ese tamaño y potencialmente escribirá fuera de los límites cuando hfsplus_read_wrapper llame a hfsplus_submit_bio y la última función lea un io_size diferente. El uso de un nuevo min_io_size establecido inicialmente en sb_min_blocksize funciona para los propósitos de la solución original, ya que se establecerá en el máximo entre HFSPLUS_SECTOR_SIZE y el primer tamaño de bloque lógico visto. Todavía usamos el máximo entre HFSPLUS_SECTOR_SIZE y min_io_size en caso de que este último no esté inicializado. Probado montando un sistema de archivos hfsplus con tamaños de bloque de bucle 512, 1024 y 4096. El informe KASAN producido antes de la corrección se ve así: [ 419.944641] ========================================================================= [ 419.945655] ERROR: KASAN: slab-use-after-free en hfsplus_read_wrapper+0x659/0xa0a [ 419.946703] Lectura de tamaño 2 en la dirección ffff88800721fc00 por la tarea repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro No contaminado 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Seguimiento de llamadas: [ 419.950384] [ 419.950676] dump_stack_lvl+0x57/0x78 [ 419.951212] ? kmem_cache_debug_flags+0xc/0x1d [ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.954231] kasan_report+0x89/0xb0 [ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.955367] hfsplus_read_wrapper+0x659/0xa0a [ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10 [ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9 [ 419.957214] ? _raw_spin_unlock+0x1a/0x2e [ 419.957772] hfsplus_fill_super+0x348/0x1590 [ 419.958355] ? hlock_class+0x4c/0x109 [ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.959499] ? __pfx_string+0x10/0x10 [ 419.960006] ? lock_acquire+0x3e2/0x454 [ 419.960532] ? bdev_name.constprop.0+0xce/0x243 [ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10 [ 419.961799] ? puntero+0x3f0/0x62f [ 419.962277] ? __pfx_pointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? __pfx_vsnprintf+0x10/0x10 [ 419.963621] ? setup_bdev_super+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? __pfx_snprintf+0x10/0x10 [ 419.964675] ? lock_acquired+0x45c/0x5e9 [ 419.965016] ? set_blocksize+0x139/0x1c1 [ 419.965381] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.966179] mount_bdev+0x12f/0x1bf [ 419.966512] ? __pfx_mount_bdev+0x10/0x10 [ 419.966886] ? vfs_parse_fs_string+0xce/0x111 [ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10 [ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10 [ 419.968073] árbol_obtención_legado+0x104/0x178 [ 419.968414] árbol_obtención_vfs+0x86/0x296 [ 419.968751] montaje_ruta+0xba3/0xd0b [ 419.969157] ? __pfx_path_mount+0x10/0x10 [ 419.969594] ? kmem_cache_free+0x1e2/0x260 [ 419.970311] montaje_ruta+0x99/0xe0 [ 419.970630] ? __pfx_do_mount+0x10/0x10 [ 419.971008] __do_sys_mount+0x199/0x1c9 [ 419.971397] do_syscall_64+0xd0/0x135 [ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Código: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: xlnx: zynqmp_disp: la capa puede ser nula al liberar la capa->info puede ser nula si tenemos un error en la primera capa en zynqmp_disp_create_layers

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg() kmalloc puede fallar, el valor de retorno puede ser NULL y provocará la desreferencia del puntero NULL. Agregue check NULL return of kmalloc in btc_fw_set_monreg().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cw1200: Se corrige una posible desreferencia NULL. Se identificó una refactorización reciente mediante un análisis estático que provoca una posible desreferencia NULL. ¡Corrija esto!

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige un problema de pérdida de memoria cuando se elimina el controlador. Ejecutar "modprobe amdgpu" por segunda vez (seguido de modprobe -r amdgpu) provoca un seguimiento de llamada como: [845.212163] El administrador de memoria no está limpio durante la eliminación. [ 845.212170] ADVERTENCIA: CPU: 4 PID: 2481 en drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x2b/0x40 [ 845.212177] Módulos vinculados en: amdgpu(OE-) amddrm_ttm_helper(OE) amddrm_buddy(OE) amdxcp(OE) amd_sched(OE) drm_exec drm_suballoc_helper drm_display_helper i2c_algo_bit amdttm(OE) amdkcl(OE) cec rc_core sunrpc qrtr intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi edac_mce_amd snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_usb_audio snd_hda_codec snd_usbmidi_lib kvm_amd snd_hda_core snd_ump mc snd_hwdep kvm snd_pcm snd_seq_midi snd_seq_midi_event irqbypass crct10dif_pclmul snd_rawmidi polyval_clmulni polyval_generic ghash_clmulni_intel sha256_ssse3 sha1_ssse3 snd_seq aesni_intel crypto_simd snd_seq_device cryptd snd_timer mfd_aaeon asus_nb_wmi eeepc_wmi joydev asus_wmi snd ledtrig_audio mapa de teclas dispersas ccp wmi_bmof leds de entrada k10temp i2c_piix4 perfil de plataforma rapl soundcore gpio_amdpt mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs tablas_ip tablas_x autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid ahci xhci_pci igc crc32_pclmul libahci xhci_pci_renesas video [ 845.212284] wmi [última descarga: amddrm_ttm_helper(OE)] [ 845.212290] CPU: 4 PID: 2481 Comm: modprobe Contaminado: GW OE 6.8.0-31-generic #31-Ubuntu [ 845.212296] RIP: 0010:drm_mm_takedown+0x2b/0x40 [ 845.212300] Código: 1f 44 00 00 48 8b 47 38 48 83 c7 38 48 39 f8 75 09 31 c0 31 ff e9 90 2e 86 00 55 48 c7 c7 d0 f6 8e 8a 48 89 e5 e8 f5 db 45 ff <0f> 0b 5d 31 c0 31 ff e9 74 2e 86 00 66 0f 1f 84 00 00 00 00 00 90 [ 845.212302] RSP: 0018:ffffb11302127ae0 EFLAGS: 00010246 [ 845.212305] RAX: 0000000000000000 RBX: ffff92aa5020fc08 RCX: 00000000000000000 [ 845.212307] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 845.212309] RBP: ffffb11302127ae0 R08: 0000000000000000 R09: 00000000000000000 [ 845.212310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004 [ 845.212312] R13: ffff92aa50200000 R14: ffff92aa5020fb10 R15: ffff92aa5020faa0 [ 845.212313] FS: 0000707dd7c7c080(0000) GS:ffff92b93de00000(0000) knlGS:0000000000000000 [ 845.212316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 845.212318] CR2: 00007d48b0aee200 CR3: 0000000115a58000 CR4: 0000000000f50ef0 [ 845.212320] PKRU: 55555554 [ 845.212321] Rastreo de llamadas: [ 845.212323] [ 845.212328] ? show_regs+0x6d/0x80 [ 845.212333] ? __warn+0x89/0x160 [ 845.212339] ? drm_mm_takedown+0x2b/0x40 [ 845.212344] ? report_bug+0x17e/0x1b0 [ 845.212350] ? handle_bug+0x51/0xa0 [ 845.212355] ? exc_invalid_op+0x18/0x80 [ 845.212359] ? asm_exc_invalid_op+0x1b/0x20 [ 845.212366] ? drm_mm_takedown+0x2b/0x40 [845.212371] amdgpu_gtt_mgr_fini+0xa9/0x130 [amdgpu] [845.212645] amdgpu_ttm_fini+0x264/0x340 [amdgpu] [845.212770] amdgpu_bo_fini+0x2e/0xc0 [amdgpu] [845.212894] gmc_v12_0_sw_fini+0x2a/0x40 [amdgpu] [845.213036] amdgpu_device_fini_sw+0x11a/0x590 [amdgpu] [845.213159] es: amdgpu_driver_release_kms+0x16/0x40 [amdgpu] [ 845.213302] devm_drm_dev_init_release+0x5e/0x90 [ 845.213305] devm_action_release+0x12/0x30 [ 845.213308] release_nodes+0x42/0xd0 [ 845.213311] devres_release_all+0x97/0xe0 [ 845.213314] device_unbind_cleanup+0x12/0x80 [ 845.213317] device_release_driver_internal+0x230/0x270 [ 845.213319] ? srso_alias_return_thunk+0x5/0xfbef5 Esto se debe a la pérdida de memoria durante la fase inicial. La primera vez que se elimina el controlador, se libera memoria, pero cuando se inserta el controlador por segunda vez, el dmub de VBIOS no está activo, ya que la política de PSP es retener la versión cargada del controlador en los arranques en caliente posteriores.---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: accel/ivpu: Evitar la invocación de recuperación durante la sonda y reanudación Refactorizar las funciones de envío y recepción de IPC para permitir la gestión correcta de operaciones que no deberían activar un proceso de recuperación. Exponer ivpu_send_receive_internal(), que ahora es utilizado por la entrada D0i3, la inicialización de DCT y las funciones de inicialización de HWS. Estas funciones se han modificado para devolver códigos de error de forma elegante, en lugar de iniciar la recuperación. Las funciones actualizadas se invocan dentro de ivpu_probe() e ivpu_resume(), lo que garantiza que cualquier error encontrado durante estas etapas dé como resultado una secuencia de desmontaje o apagado adecuada. El enfoque anterior de activar la recuperación dentro de estas funciones podría conducir a una condición de ejecución, lo que podría causar un comportamiento indefinido y fallas del kernel debido a desreferencias de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: Se corrige la advertencia de escritura que abarca el campo memcpy() en mwifiex_config_scan() Reemplace la matriz de un elemento con un miembro de matriz flexible en `struct mwifiex_ie_types_wildcard_ssid_params` para corregir la siguiente advertencia en una Chromebook MT8173 (mt8173-elm-hana): [ 356.775250] ------------[ cortar aquí ]------------ [ 356.784543] memcpy: se detectó escritura que abarca el campo (tamaño 6) del campo único "wildcard_ssid_tlv->ssid" en drivers/net/wireless/marvell/mwifiex/scan.c:904 (tamaño 1) [ 356.813403] ADVERTENCIA: CPU: 3 PID: 742 en drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex] El "(tamaño 6)" anterior es exactamente la longitud del SSID de la red a la que estaba conectado este dispositivo. La fuente de la advertencia se ve así: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len); Hay un #define WILDCARD_SSID_TLV_MAX_SIZE que usa sizeof() en esta estructura, pero ya no tenía en cuenta el tamaño de la matriz de un elemento, por lo que no es necesario cambiarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: zynqmp_kms: Desconectar el dispositivo DRM antes de quitarlo. Evite que los accesos al espacio de usuario del dispositivo DRM provoquen use-after-frees desconectando el dispositivo antes de quitarlo. Esto hace que cualquier otro acceso al espacio de usuario genere un error sin más llamadas a los componentes internos de este controlador.