Vulnerabilidades

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: 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: 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: 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: 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.

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: ath12k: arreglo de use-after-free en ath12k_dp_cc_cleanup() Durante la eliminación del módulo ath12k, en ath12k_core_deinit(), ath12k_mac_destroy() anula el registro de ah->hw de mac80211 y libera el ah->hw así como todos los ar en él. Después de esto, ath12k_core_soc_destroy()-> ath12k_dp_free()-> ath12k_dp_cc_cleanup() intenta acceder a uno de los ar liberados del skb pendiente. Esto se debe a que durante la destrucción de mac, el controlador no pudo limpiar algunos paquetes de datos, a los que se accedió más tarde en ath12k_dp_cc_cleanup() y se liberaron, pero el uso de ar del paquete provocó este use-after-free. ERROR: KASAN: use-after-free en ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k] Escritura de tamaño 4 en la dirección ffff888150bd3514 por la tarea modprobe/8926 CPU: 0 UID: 0 PID: 8926 Comm: modprobe No contaminado 6.11.0-rc2-wt-ath+ #1746 Nombre del hardware: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 28/05/2021 Seguimiento de llamadas: dump_stack_lvl+0x7d/0xe0 dirección_de_impresión_descripción.constprop.0+0x33/0x3a0 informe_de_impresión+0xb5/0x260 ? dirección_kasan_a_losa+0x24/0x80 informe_kasan+0xd8/0x110 ? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k] ? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k] rango de comprobación de kasan+0xf3/0x1a0 __comprobación de escritura de kasan+0x14/0x20 ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k] dp_free+0x178/0x420 [ath12k] núcleo_detención+0x176/0x200 [ath12k] núcleo_deinit+0x13f/0x210 [ath12k] eliminación de pci+0xad/0x1c0 [ath12k] eliminación de dispositivo pci+0x9b/0x1b0 dispositivo_eliminar+0xbf/0x150 dispositivo_liberación_controlador_interno+0x3c3/0x580 ? __kasan_check_read+0x11/0x20 controlador_desconectar+0xc4/0x190 bus_eliminar_controlador+0x130/0x2a0 controlador_anular_registro+0x68/0x90 pci_anular_registro_controlador+0x24/0x240 ? buscar_módulo_todos+0x13e/0x1e0 ath12k_pci_exit+0x10/0x20 [ath12k] __do_sys_eliminar_módulo+0x32c/0x580 ? módulo_indicadores+0x2f0/0x2f0 ? kmem_cache_libre+0xf0/0x410 ? __fput+0x56f/0xab0 ? __fput+0x56f/0xab0 ? debug_smp_processor_id+0x17/0x20 __x64_sys_delete_module+0x4f/0x70 x64_sys_call+0x522/0x9f0 do_syscall_64+0x64/0x130 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f8182c6ac8b Commit 24de1b7b231c ("wifi: ath12k: corregir falla de vaciado en escenarios de recuperación") agregó el cambio para disminuir el conteo de paquetes pendientes en caso de recuperación, lo que tiene sentido ya que ah->hw y todos los ar en él están intactos durante la recuperación, pero durante la desincialización del núcleo no tiene sentido disminuir el conteo de paquetes o despertar el waitq vacío ya que el módulo también se eliminará. Los paquetes de skb pendientes no se pueden usar y los paquetes deberían simplemente liberarse. Para solucionar esto, evite acceder a ar desde skb->cb cuando se está anulando el registro del controlador. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1 Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

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: 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: Bluetooth: btmtk: ajuste la posición para inicializar el ancla de datos iso. La inicialización del ancla de datos iso de MediaTek debe moverse a donde MediaTek afirma que tiene interfaz de datos iso. Si hay una desconexión USB de BT inesperada durante el flujo de configuración, provocará un problema de bloqueo del puntero NULL al liberar el ancla iso, ya que el ancla aún no se había inicializado. Ajuste la posición para inicializar el ancla de datos iso. [ 17.137991] pc : usb_kill_anchored_urbs+0x60/0x168 [ 17.137998] lr : usb_kill_anchored_urbs+0x44/0x168 [ 17.137999] sp : ffffffc0890cb5f0 [ 17.138000] x29: ffffffc0890cb5f0 x28: ffffff80bb6c2e80 [ 17.144081] gpio gpiochip0: identificador chardev registrado para 1 líneas [ 17.148421] x27: 0000000000000000 [ 17.148422] x26: ffffffd301ff4298 x25: 00000000000000003 x24: 00000000000000f0 [ 17.148424] x23: 0000000000000000 x22: 00000000ffffffff x21: 0000000000000001 [ 17.148425] x20: ffffffffffffffd8 x19: ffffff80c0f25560 x18: 0000000000000000 [ 17.148427] x17: ffffffd33864e408 x16: ffffffd33808f7c8 x15: 0000000000200000 [ 17.232789] x14: e0cd73cf80ffffff x13: 50f2137c0a0338c9 x12: 0000000000000001 [ 17.239912] x11: 0000000080150011 x10: 0000000000000002 x9: 0000000000000001 [ 17.247035] x8: 0000000000000000 x7: 0000000000008080 x6: 8080000000000000 [ 17.254158] x5: ffffffd33808ebc0 x4 : fffffffe033dcf20 x3 : 0000000080150011 [ 17.261281] x2 : ffffff8087a91400 x1 : 0000000000000000 x0 : ffffff80c0f25588 [ 17.268404] Rastreo de llamadas: [ 17.270841] usb_kill_anchored_urbs+0x60/0x168 [ 17.275274] btusb_mtk_release_iso_intf+0x2c/0xd8 [btusb (HASH:5afe 6)] [ 17.284226] btusb_mtk_disconnect+0x14/0x28 [btusb (HASH:5afe 6)] [ 17.292652] btusb_disconnect+0x70/0x140 [btusb (HASH:5afe 6)] [ 17.300818] interfaz_desvinculación_usb+0xc4/0x240 [ 17.305079] controlador_liberación_dispositivo_interno+0x18c/0x258 [ 17.310296] controlador_liberación_dispositivo+0x1c/0x30 [ 17.314557] dispositivo_eliminación_bus+0x140/0x160 [ 17.318643] dispositivo_del+0x1c0/0x330 [ 17.322121] usb_disable_device+0x80/0x180 [ 17.326207] usb_disconnect+0xec/0x300 [ 17.329948] hub_quiesce+0x80/0xd0 [ 17.333339] hub_disconnect+0x44/0x190 [ 17.337078] usb_unbind_interface+0xc4/0x240 [ 17.341337] device_release_driver_internal+0x18c/0x258 [ 17.346551] device_release_driver+0x1c/0x30 [ 17.350810] usb_driver_release_interface+0x70/0x88 [ 17.355677] El0_svc_common+0x84/0xe0 [ 17.378030] El0_svc+0x20/0x30 [ 17.381334] El0_svc+0x34/0x60 [ 17.384382] el0t_64_sync_handler+0x88/0xf0 [ 17.388554] el0t_64_sync+0x180/0x188 [ 17.392208] Código: f9400677 f100a2f4 54fffea0 d503201f (b8350288) [ 17.398289] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: isofs: evitar pérdida de memoria en iocharset Se encontró una pérdida de memoria como la siguiente: objeto sin referencia 0xffff0000d10164d8 (tamaño 8): comm "pool-udisksd", pid 108217, jiffies 4295408555 volcado hexadecimal (primeros 8 bytes): 75 74 66 38 00 cc cc cc utf8.... backtrace (crc de430d31): [] kmemleak_alloc+0xb8/0xc8 [] __kmalloc_node_track_caller_noprof+0x380/0x474 [] kstrdup+0x70/0xfc [] parámetro_parse_isofs+0x228/0x2c0 [isofs] [] parámetro_fs_parse_vfs+0xf4/0x164 [] cadena_fs_parse_vfs+0x8c/0xd4 [] sep_monolítico_vfs+0xb0/0xfc [] parámetro_monolítico_genérico+0x30/0x3c [] analizar_datos_de_montaje_monolítico+0x40/0x4c [] ruta_de_montaje+0x6c4/0x9ec [] hacer_montaje+0xac/0xc4 [] __arm64_montaje_del_sistema+0x16c/0x2b0 [] invocar_llamada_del_sistema+0x7c/0x104 [] el0_svc_common.constprop.1+0xe0/0x104 [] do_el0_svc+0x2c/0x38 [] el0_svc+0x3c/0x1b8 El opt->iocharset se libera dentro de la función isofs_fill_super, pero puede haber situaciones en las que no sea posible ingresar a esta función. Por ejemplo, en la función get_tree_bdev_flags, cuando se encuentra la situación en la que "No se puede montar, cambiaría el estado de RO", en tal caso, isofs_fill_super no tendrá la oportunidad de ser llamado, lo que significa que opt->iocharset no tendrá la oportunidad de ser liberado, lo que finalmente conduce a una pérdida de memoria. Pasemos la liberación de memoria de opt->iocharset a la función isofs_free_fc.