Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: ipq8074: fix PCI-E clock oops Corrige los errores del kernel relacionados con el reloj PCI-E que son causados por un reloj padre faltante. pcie0_rchng_clk_src tiene num_parents establecido en 2, pero solo un padre está realmente establecido a través de parent_hws, también debería tener "XO" definido. Esto hará que el kernel entre en pánico en un puntero NULL en clk_core_get_parent_by_index(). Entonces, para solucionar esto, utilice clk_parent_data para proporcionar los datos del padre gcc_xo_gpll0. Dado que ya existe un static const char * const gcc_xo_gpll0[] utilizado para proporcionar los mismos padres a través de parent_names, convierta esos usuarios a clk_parent_data también. Sin este earlycon es necesario incluso para detectar el OOPS ya que reiniciará la placa antes de que se inicialice el serial con lo siguiente: [0.232279] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0000a00000000000 [0.232322] Información de aborto de memoria: [0.239094] ESR = 0x96000004 [0.241778] EC = 0x25: DABT (EL actual), IL = 32 bits [0.244908] SET = 0, FnV = 0 [0.250377] EA = 0, S1PTW = 0 [0.253236] FSC = 0x04: falla de traducción de nivel 0 [0.256277] Información de aborto de datos: [0.261141] ISV = 0, ISS = 0x00000004 [ 0.264262] CM = 0, WnR = 0 [ 0.267820] [0000a00000000000] dirección entre los rangos de direcciones del usuario y del núcleo [ 0.270954] Error interno: Oops: 96000004 [#1] SMP [ 0.278067] Módulos vinculados en: [ 0.282751] CPU: 1 PID: 1 Comm: swapper/0 No contaminado 5.15.10 #0 [ 0.285882] Nombre del hardware: Xiaomi AX3600 (DT) [ 0.292043] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0,296299] pc: clk_core_get_parent_by_index+0x68/0xec [0,303067] lr: __clk_register+0x1d8/0x820 [0,308273] sp: ffffffc01111b7d0 [0,312438] x29: ffffffc01111b7d0 x28: 0000000000000000 x27: 0000000000000040 [0,315919] x26: 000000000000002 x25: 0000000000000000 x24: ffffff8000308800 [ 0,323037] x23: ffffff8000308850 x22: ffffff8000308880 x21: ffffff8000308828 [ 0,330155] x20: 0000000000000028 x19: ffffff8000309700 x18: 0000000000000020 [ 0,337272] x17: 000000005cc86990 x16: 0000000000000004 x15: ffffff80001d9d0a [ 0,344391] x14: 0000000000000000 x13: 00000000000000000 x12: 0000000000000006 [ 0.351508] x11: 0000000000000003 x10: 0101010101010101 x9 : 0000000000000000 [ 0.358626] x8 : 7f7f7f7f7f7f7f7f x7 : 6468626f5e626266 x6 : 17000a3a403c1b06 [ 0.365744] x5 : 061b3c403a0a0017 x4 : 000000000000000 x3 : 0000000000000001 [ 0.372863] x2 : 0000a00000000000 x1 : 0000000000000001 x0 : ffffff8000309700 [ 0.379982] Rastreo de llamadas: [ 0.387091] clk_core_get_parent_by_index+0x68/0xec [ 0.389351] __clk_register+0x1d8/0x820 [ 0.394210] devm_clk_hw_register+0x5c/0xe0 [ 0.398030] devm_clk_register_regmap+0x44/0x8c [ 0.402198] qcom_cc_really_probe+0x17c/0x1d0 [ 0.406711] qcom_cc_probe+0x34/0x44 [ 0.411224] gcc_ipq8074_probe+0x18/0x30 [ 0.414869] platform_probe+0x68/0xe0 [ 0.418776] really_probe.part.0+0x9c/0x30c [ 0.422336] __driver_probe_device+0x98/0x144 [ 0.426329] driver_probe_device+0x44/0x11c [ 0.430842] __device_attach_driver+0xb4/0x120 [ 0.434836] bus_for_each_drv+0x68/0xb0 [ 0.439349] __device_attach+0xb0/0x170 [ 0.443081] device_initial_probe+0x14/0x20 [ 0.446901] bus_probe_device+0x9c/0xa4 [ 0.451067] device_add+0x35c/0x834 [ 0.454886] of_device_add+0x54/0x64 [ 0.458360] of_platform_device_create_pdata+0xc0/0x100 [ 0.462181] of_platform_bus_create+0x114/0x370 [ 0.467128] of_platform_bus_create+0x15c/0x370 [ 0.471641] of_platform_populate+0x50/0xcc [ 0.476155] of_platform_default_populate_init+0xa8/0xc8 [ 0.480324] do_one_initcall+0x50/0x1b0 [ 0.485877] kernel_init_freeable+0x234/0x29c [ 0.489436] kernel_init+0x24/0x120 [ 0.493948] ret_from_fork+0x10/0x20 [ 0.497253] Código: d50323bf d65f03c0 f94002a2 b4000302 (f9400042) [ 0.501079] ---[ fin del seguimiento 4ca7e1129da2abce ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpu: host1x: Se corrige una pérdida de memoria en 'host1x_remove()'. Se agrega una llamada 'host1x_channel_list_free()' faltante en la función de eliminación, como ya se hizo en la ruta de manejo de errores de la función de sonda.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udmabuf: validar ubuf->pagecount Syzbot ha informado de un GPF en sg_alloc_append_table_from_pages(). El problema estaba en ubuf->pages == ZERO_PTR. ubuf->pagecount se calcula a partir de los argumentos pasados desde el espacio de usuario. Si el usuario crea udmabuf con list.size == 0, entonces ubuf->pagecount también será igual a cero; esto hace que kmalloc_array() devuelva ZERO_PTR. Arréglelo validando ubuf->pagecount antes de pasarlo a kmalloc_array().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: soc-compress: evita el posible uso de un puntero nulo Hay un seguimiento de llamada que snd_soc_register_card() ->snd_soc_bind_card()->soc_init_pcm_runtime() ->snd_soc_dai_compress_new()->snd_soc_new_compress(). En el seguimiento, 'codec_dai' se transfiere desde card->dai_link, y podemos ver desde snd_soc_add_pcm_runtime() en snd_soc_bind_card() que, si el valor de card->dai_link->num_codecs es 0, entonces 'codec_dai' podría ser un puntero nulo causado por un índice fuera de los límites en 'asoc_rtd_to_codec(rtd, 0)'. Además, varias plataformas llaman a snd_soc_register_card(), por lo que es mejor agregar la verificación en caso de uso incorrecto. Y como 'cpu_dai' ya se ha verificado en soc_init_pcm_runtime(), no es necesario volver a verificar. Si se agrega la verificación de la siguiente manera, si 'codec_dai' es nulo, snd_soc_new_compress() no pasará la verificación 'if (playback + capture != 1)', lo que evita el uso sobrante de 'codec_dai'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: rpmpd: Verificar el retorno nulo de devm_kcalloc Debido al posible fallo de la asignación, data->domains podría ser un puntero NULL y provocará la desreferencia del puntero NULL más adelante. Por lo tanto, podría ser mejor verificarlo y devolver directamente -ENOMEM sin liberar los datos manualmente si falla, porque el comentario de devm_kmalloc() dice "La memoria asignada con esta función se libera automáticamente al desconectar el controlador".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: smscufx: Corregir null-ptr-deref en ufx_usb_probe() Recibí un informe de null-ptr-deref: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 ... RIP: 0010:fb_destroy_modelist+0x38/0x100 ... Seguimiento de llamadas: ufx_usb_probe.cold+0x2b5/0xac1 [smscufx] usb_probe_interface+0x1aa/0x3c0 [usbcore] really_probe+0x167/0x460 ... ret_from_fork+0x1f/0x30 Si fb_alloc_cmap() falla en ufx_usb_probe(), fb_destroy_modelist() Se llamará a modelist para destruirlo en la ruta de manejo de errores. Pero modelist aún no se ha inicializado, por lo que dará como resultado null-ptr-deref. Inicialice modelist antes de llamar a fb_alloc_cmap() para corregir este error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath5k: corrección de OOB en ath5k_eeprom_read_pcal_info_5111 El error se encontró durante el fuzzing. Stacktrace lo ubica en ath5k_eeprom_convert_pcal_info_5111. Cuando no se selecciona ninguna de las curvas en el bucle, idx puede llegar hasta AR5K_EEPROM_N_PD_CURVES. La línea hace que pd esté fuera de los límites. pd = &chinfo[pier].pd_curves[idx]; Hay muchas escrituras OOB que usan pd más adelante en el código. Así que agregué una verificación de cordura para idx. No se necesitan verificaciones para otros bucles que involucran AR5K_EEPROM_N_PD_CURVES ya que el índice del bucle no se usa fuera de los bucles. El parche NO se prueba con un dispositivo real. El siguiente es el informe de fuzzing ERROR: KASAN: slab-out-of-limits en ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] Escritura de tamaño 1 en la dirección ffff8880174a4d60 por la tarea modprobe/214 CPU: 0 PID: 214 Comm: modprobe No contaminado 5.6.0 #1 Seguimiento de llamadas: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] __kasan_report.cold+0x37/0x7c ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] kasan_report+0xe/0x20 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] ath5k_eeprom_init+0x2513/0x6290 [ath5k] ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? usleep_range+0xb8/0x100 ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] ath5k_hw_init+0xb60/0x1970 [ath5k] ath5k_init_ah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5k_stop+0x140/0x140 [ath5k] ? _dev_notice+0xf6/0xf6 ? apic_timer_interrupt+0xa/0x20 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] ? mutex_lock+0x89/0xd0 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 ? pci_device_remove+0x280/0x280 ? pci_device_remove+0x280/0x280 realmente_probe+0x209/0x5d0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubi: Se corrige la condición de ejecución entre ctrl_cdev_ioctl y ubi_cdev_ioctl Hulk Robot informó un informe de KASAN sobre use-after-free: ====================================================================== ERROR: KASAN: use-after-free en __list_del_entry_valid+0x13d/0x160 Lectura de tamaño 8 en la dirección ffff888035e37d98 por la tarea ubiattach/1385 [...] Seguimiento de llamadas: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Asignado por la tarea 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Liberado por la tarea 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ===================================================================== El bloqueo retenido por ctrl_cdev_ioctl es ubi_devices_mutex, pero el bloqueo retenido por ubi_cdev_ioctl es ubi->device_mutex. Por lo tanto, los dos bloqueos pueden ser concurrentes. ctrl_cdev_ioctl contiene dos operaciones: ubi_attach y ubi_detach. ubi_detach está libre de errores porque utiliza el conteo de referencias para evitar la concurrencia. Sin embargo, uif_init y uif_close en ubi_attach pueden competir con ubi_cdev_ioctl. uif_init competirá con ubi_cdev_ioctl como en la siguiente pila. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs existen kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // primer ubi_free_volume libre cdev_del // doble liberación cdev_device_del Y uif_close competirá con ubi_cdev_ioctl como en la siguiente pila. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // primera liberación ubi_free_volume // doble liberación La causa de este problema es que la confirmación 714fb87e8bc0 hace que el dispositivo esté "disponible" antes de que se pueda acceder a él a través de sysfs. Por lo tanto, revertimos la modificación. Solucionaremos la condición de ejecución entre la creación del dispositivo ubi y udev eliminando ubi_get_device en vol_attribute_show y dev_attribute_show. Esto evita el acceso a ubi_devices[ubi_num] no inicializados. ubi_get_device se utiliza para evitar que se eliminen los dispositivos durante la ejecución de sysfs. Sin embargo, ahora kernfs garantiza que los dispositivos no se eliminarán antes de que se liberen todos los recuentos de referencias. El proceso clave se muestra en la siguiente pila. device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: Corrección para agregar refcount una vez que la página se establece como privada MM definió la regla [1] muy claramente que una vez que la página se establece con el indicador PG_private, debemos incrementar el refcount en esa página, también los flujos principales como pageout(), migrants_page() asumirán que hay un recuento de referencia de página adicional si page_has_private() devuelve verdadero. De lo contrario, podemos obtener un ERROR en la migración de la página: page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:"f30e" flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) página volcada porque: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cortar aquí ]------------ ¡ERROR del kernel en include/linux/page_ref.h:184! código de operación no válido: 0000 [#1] CPU SMP: 3 PID: 38 Comm: kcompactd0 No contaminado 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Rastreo de llamadas: ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrants_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Antes de tiempo, deberíamos aclarar un concepto, qué significa refcount en la página obtenida de grab_cache_page_write_begin(). Hay 2 situaciones: Situación 1: refcount es 3, la página es creada por __page_cache_alloc. TYPE_A - el proceso de escritura está usando esta página TYPE_B - la página es asignada a un cierto mapeo llamando a __add_to_page_cache_locked() TYPE_C - la página es agregada a la lista pagevec correspondiente a la CPU actual llamando a lru_cache_add() Situación 2: refcount es 2, la página es obtenida del árbol del mapeo TYPE_B - la página ha sido asignada a un cierto mapeo TYPE_A - el proceso de escritura está usando esta página (llamando a page_cache_get_speculative()) El sistema de archivos libera un refcount llamando a put_page() en xxx_write_end(), el refcount liberado corresponde a TYPE_A (la tarea de escritura lo está usando). Si hay algún proceso usando una página, el proceso de migración de página omitirá la página al juzgar si expected_page_refs() es igual a page refcount. El ERROR es causado por el siguiente proceso: PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // coloca la página en el pagevec de la CPU 0 (refcnf = 3, para el proceso de creación de la página) ubifs_write_end SetPagePrivate(page_a) // ¡no aumenta el número de páginas! unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // traverse all pages in cpu 0's pagevec __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate_migratepages_block get_page_unless_zero(page_a) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS no aumenta el recuento de referencias de la página después de configurar el indicador privado, lo que hace que la tarea de migración de la página crea que ningún otro proceso utiliza la página, por lo que se migra la página. Esto provoca un acceso simultáneo al recuento de referencias de la página entre put_page() llamado por otro proceso (por ejemplo, el proceso de lectura llama a lru_cache_add) y page_ref_unfreeze() llamado por mi ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: Se corrige la lectura fuera de los límites en la función ubifs_wbuf_write_nolock() ubifs_wbuf_write_nolock() puede acceder a buf fuera de los límites en el siguiente proceso: ubifs_wbuf_write_nolock(): classified_len = ALIGN(len, 8); // Supongamos que len = 4089, classified_len = 4096 if (aligned_len <= wbuf->avail) ... // No satisface if (wbuf->used) { ubifs_leb_write() // Complete algunos datos en avail wbuf len -= wbuf->avail; // len aún no está alineado a 8 bytes classified_len -= wbuf->avail; } n = classified_len >> c->max_write_shift; if (n) { n <<= c->max_write_shift; err = ubifs_leb_write(c, wbuf->lnum, buf + escrito, wbuf->offs, n); // n > len, lectura fuera de los límites menor a 8(n-len) bytes }, lo cual puede ser detectado por KASAN: =========================================================== ERROR: KASAN: slab fuera de los límites en ecc_sw_hamming_calculate+0x1dc/0x7d0 Lectura de tamaño 4 en la dirección ffff888105594ff8 por la tarea kworker/u8:4/128 Cola de trabajo: escritura diferida wb_workfn (flush-ubifs_0_0) Rastreo de llamadas: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs] write_head+0xdc/0x1c0 [ubifs] ubifs_jnl_write_inode+0x627/0x960 [ubifs] wb_workfn+0x8af/0xb80 La función ubifs_wbuf_write_nolock() acepta que el parámetro 'len' no esté alineado con 8 bytes, 'len' representa la longitud verdadera de buf (que está asignada en 'ubifs_jnl_xxx', p. ej. ubifs_jnl_write_inode), por lo que ubifs_wbuf_write_nolock() debe manejar la longitud leída de 'buf' con cuidado para escribir leb de forma segura. Obtenga un reproductor en [Enlace].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> ubifs: Se corrige interbloqueo en concurrencia de un renombrado con whiteout simultáneo a la escritura del inodo.<br /> <br /> Tareas colgadas:<br /> [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132<br /> [ 77.028820] Call Trace:<br /> [ 77.029027] schedule+0x8c/0x1b0<br /> [ 77.029067] mutex_lock+0x50/0x60<br /> [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs]<br /> [ 77.029117] __writeback_single_inode+0x43c/0x570<br /> [ 77.029128] writeback_sb_inodes+0x259/0x740<br /> [ 77.029148] wb_writeback+0x107/0x4d0<br /> [ 77.029163] wb_workfn+0x162/0x7b0<br /> <br /> [ 92.390442] task:aa state:D stack: 0 pid: 1506<br /> [ 92.390448] Call Trace:<br /> [ 92.390458] schedule+0x8c/0x1b0<br /> [ 92.390461] wb_wait_for_completion+0x82/0xd0<br /> [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110<br /> [ 92.390472] writeback_inodes_sb_nr+0x14/0x20<br /> [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs]<br /> [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs]<br /> [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs]<br /> [ 92.390571] vfs_rename+0xdb2/0x1170<br /> [ 92.390580] do_renameat2+0x554/0x770<br /> <br /> , ocasionado por procesos simultáneos de renombrado con whiteout y escritura del inodo:<br /> rename_whiteout(Thread 1) wb_workfn(Thread2)<br /> ubifs_rename<br /> do_rename<br /> lock_4_inodes (Hold ui_mutex)<br /> ubifs_budget_space<br /> make_free_space<br /> shrink_liability<br /> __writeback_inodes_sb_nr<br /> bdi_split_work_to_wbs (Queue new wb work)<br /> wb_do_writeback(wb work)<br /> __writeback_single_inode<br /> ubifs_write_inode<br /> LOCK(ui_mutex)<br /> ?<br /> wb_wait_for_completion (Wait wb work) &amp;lt;-- ¡interbloqueo!<br /> <br /> Caso de prueba:<br /> 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT)<br /> 2. Consumir todo el espacio antes de que kernel(mdelay) planifique el whiteout<br /> <br /> Arreglado calculando el espacio de whiteout antes de bloquear los inodos de ubifs.<br /> <br /> También soluciona etiqueta la etiqueta goto errónea &amp;#39;out_release&amp;#39; en el flujo de errores<br /> de la planificación del whiteout (al menos debería recuperar el directorio i_size y desbloquear 4 inodos de ubifs).<br />

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: rename_whiteout: Se corrige la doble liberación para whiteout_ui-&amp;gt;data &amp;#39;whiteout_ui-&amp;gt;data&amp;#39; se liberará dos veces si el presupuesto de espacio falla para la operación de cambio de nombre de whiteout como el siguiente proceso: rename_whiteout dev = kmalloc whiteout_ui-&amp;gt;data = dev kfree(whiteout_ui-&amp;gt;data) // Libera la primera vez iput(whiteout) ubifs_free_inode kfree(ui-&amp;gt;data) // ¡Doble liberación! KASAN informa: ==================================================================== ERROR: KASAN: liberación doble o liberación no válida en ubifs_free_inode+0x4f/0x70 Seguimiento de llamadas: kfree+0x117/0x490 ubifs_free_inode+0x4f/0x70 [ubifs] i_callback+0x30/0x60 rcu_do_batch+0x366/0xac0 __do_softirq+0x133/0x57f Asignado por la tarea 1506: kmem_cache_alloc_trace+0x3c2/0x7a0 do_rename+0x9b7/0x1150 [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 Liberado por la tarea 1506: kfree+0x117/0x490 do_rename.cold+0x53/0x8a [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 La dirección con errores pertenece al objeto en ffff88810238bed8 que pertenece al caché kmalloc-8 de tamaño 8 ===================================================================== Deje que ubifs_free_inode() libere &amp;#39;whiteout_ui-&amp;gt;data&amp;#39;. Por cierto, elimine la asignación no utilizada &amp;#39;whiteout_ui-&amp;gt;data_len = 0&amp;#39;, el proceso &amp;#39;ubifs_evict_inode() -&amp;gt; ubifs_jnl_delete_inode() -&amp;gt; ubifs_jnl_write_inode()&amp;#39; no lo necesita (porque &amp;#39;inc_nlink(whiteout)&amp;#39; no será ejecutado por &amp;#39;goto out_release&amp;#39;, y el nlink del inodo whiteout es 0).