Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrige el índice fuera de los límites en la traducción del formato de hardware degamma Corrige el problema del índice fuera de los límites en la función `cm_helper_translate_curve_to_degamma_hw_format`. El problema podría ocurrir cuando el índice 'i' excede el número de puntos de función de transferencia (TRANSFER_FUNC_POINTS). La corrección agrega una verificación para garantizar que 'i' esté dentro de los límites antes de acceder a los puntos de función de transferencia. Si 'i' está fuera de los límites, la función devuelve falso para indicar un error. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.blue' 1025 <= s32max

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar use-after-free en ext4_ext_insert_extent() Como mencionó Ojaswin en Link, en ext4_ext_insert_extent(), si la ruta se reasigna en ext4_ext_create_new_leaf(), usaremos la ruta obsoleta y causaremos UAF. A continuación, se muestra un seguimiento de muestra con valores ficticios: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* aquí la ruta sigue siendo 2000, UAF! */ eh = path[depth].p_hdr ===================================================================== ERROR: KASAN: slab-use-after-free en ext4_ext_insert_extent+0x26d4/0x3330 Lectura de tamaño 8 en la dirección ffff8881027bf7d0 por la tarea kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 No contaminado 6.11.0-rc2-dirty #866 Seguimiento de llamadas: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Asignado por la tarea 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Liberado por la tarea 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...]================================================================== Así que use *ppath para actualizar el path para evitar el problema de arriba

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de slab-use-after-free en ext4_split_extent_at() Nos topamos con el siguiente use after free: ====================================================================== ERROR: KASAN: slab-use-after-free en ext4_split_extent_at+0xba8/0xcc0 Lectura de tamaño 2 en la dirección ffff88810548ed08 por la tarea kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 No contaminado 6.9.0-dirty #724 Seguimiento de llamadas: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Asignado por la tarea 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Liberado por la tarea 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================== El flujo de activación del problema es el siguiente: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // devuelve -ENOMEM o -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. Si err es -ENOMEM: ext4_ext_dirty(path + path->p_depth) // ¡¡¡path use after free!!! b. Si err es -EIO y tenemos EXT_DEBUG definido: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // ¡¡¡La ruta también es use after free!!! Por lo tanto, cuando intente poner a cero o corregir la longitud de la extensión, llame a ext4_find_extent() para actualizar la ruta. Además, usamos *ppath directamente como una entrada de ext4_ext_show_leaf() para evitar un posible use after free cuando se define EXT_DEBUG y para evitar actualizaciones de ruta innecesarias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de un problema en alloc_flex_gd() Wesley informó de un problema: ======================================================================= EXT4-fs (dm-5): cambio de tamaño del sistema de archivos de 7168 a 786432 bloques ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs No contaminado 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Rastreo de llamadas: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e == ... Tome n=0,flexbg_size=16 como ejemplo: last:15 |o---------------|--------------n-| o_group:0 redimensionar a n_group:30 El reproductor correspondiente es: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Elimine el problema más 1 para solucionar el problema y agregue un WARN_ON_ONCE() para evitar que el problema vuelva a ocurrir. [ Nota: otro reprocesador que esta confirmación corrige es: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: omapdrm: Agregar comprobación faltante para alloc_ordered_workqueue, ya que puede devolver un puntero NULL y provocar una desreferencia del puntero NULL. Agregar comprobación para el valor de retorno de alloc_ordered_workqueue.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: actualización de orig_path en ext4_find_extent() En ext4_find_extent(), si la ruta no es lo suficientemente grande, la liberamos y establecemos *orig_path en NULL. Pero después de reasignar e inicializar correctamente la ruta, no actualizamos *orig_path, en cuyo caso el llamador obtiene una ruta válida pero un ppath NULL, y esto puede causar una desreferencia de puntero NULL o una pérdida de memoria de ruta. Por ejemplo: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // ¡Desreferencia de puntero NULL! ===================================================================== ERROR: Desreferencia de puntero NULL del núcleo, dirección: 000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress No contaminado 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Rastreo de llamada: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ====================================================================== Por lo tanto, *orig_path se actualiza cuando la búsqueda de extensión tiene éxito, de modo que el llamador puede usar path o *ppath de forma segura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corregir el doble brelse() del búfer de la ruta de las extensiones En ext4_ext_try_to_merge_up(), establezca path[1].p_bh en NULL después de que se haya liberado, de lo contrario, puede liberarse dos veces. Un ejemplo de lo que desencadena esto es el siguiente: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. hacer split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // devuelve -ENOMEM |// obtiene el error e intenta poner a cero |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> no establecido en NULL aquí |// puesta a cero exitosa // 2. actualizar ruta ext4_find_extent // 3. hacer split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh sigue siendo el valor anterior ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse un buffer dos veces Finalmente obtuve la siguiente ADVERTENCIA al eliminar el buffer de lru: =============================================== VFS: brelse: Intentando liberar búfer libre ADVERTENCIA: CPU: 2 PID: 72 en fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 No contaminado 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Seguimiento de llamadas: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: corregir UAF en torno a la destrucción de cola Actualmente hacemos cosas como poner en cola el paso de destrucción final en un wq de sistema aleatorio, que sobrevivirá a la instancia del controlador. Con un mal momento, podemos desmantelar el controlador con una o más colas de trabajo de trabajo aún activas, lo que genera varios splats de UAF. Agregue un paso fini para garantizar que las colas de usuario se desmantelen correctamente. En este punto, GuC ya debería estar destruido, por lo que la cola en sí ya no debería ser referenciada desde el punto de vista del hardware. v2 (Matt B): parece mucho más seguro usar una cola de espera y luego simplemente esperar a que xa_array se vacíe antes de activar el drenaje. (seleccionado de el commit 861108666cc0e999cffeab6aff17b662e68774e3)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: asignar EBADMSG a nfserr_io para evitar advertencias Ext4 arrojará -EBADMSG a través de ext4_readdir cuando se produzca un error de suma de comprobación, lo que dará como resultado la siguiente ADVERTENCIA. Solucione el problema asignando EBADMSG a nfserr_io. nfsd_buffered_readdir iterar_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify advertir_sin_espacio_para_csum __ advertir_sin_espacio_para_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // ADVERTENCIA [ 161.115610] ------------[ cortar aquí ]------------ [ 161.116465] nfsd: no estándar errno: -74 [ 161.117315] ADVERTENCIA: CPU: 1 PID: 780 en fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Módulos vinculados en: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd No contaminado 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Código: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 fffff52000 1c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 00000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ [161.142076] Rastreo de llamadas: [161.142575] ? __warn+0x9b/0x140 [161.143229] ? nfserrno+0x9d/0xd0 [161.143872] ? report_bug+0x125/0x150 [161.144595] ? handle_bug+0x41/0x90 [161.145284] ? exc_invalid_op+0x14/0x70 [161.146009] ? asm_exc_invalid_op+0x12/0x20 [161.146816] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? esperar_escrituras_concurrentes+0x170/0x170 [ 161.151004] ? tamaño_de_archivo_genérico_llseek+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? escritura_bytes_en_xdr_buf+0x97/0xe0 [ 161.157598] ? __escritura_bytes_en_xdr_buf+0xd0/0xd0 [ 161.158494] ? bloqueo_downgrade+0x90/0x90 [ 161.159232] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: se corrige una posible desreferencia de puntero nulo en ocfs2_set_buffer_uptodate. Al realizar una limpieza, si hay indicadores sin OCFS2_BH_READAHEAD, puede provocar una desreferencia de puntero NULL en el siguiente ocfs2_set_buffer_uptodate() si bh es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: recurso: corregir region_intersects() frente a add_memory_driver_managed() En un sistema con memoria CXL, el árbol de recursos (/proc/iomem) relacionado con la memoria CXL puede parecerse a lo siguiente. 490000000-50fffffff: CXL Window 0 490000000-50fffffff: region0 490000000-50fffffff: dax0.0 490000000-50fffffff: RAM del sistema (kmem) Debido a que drivers/dax/kmem.c llama a add_memory_driver_managed() durante la conexión en línea de la memoria CXL, lo que hace que "System RAM (kmem)" sea un descendiente de "CXL Window X". Esto confunde a region_intersects(), que espera que todos los recursos de "RAM del sistema" estén en el nivel superior de iomem_resource. Esto puede provocar errores. Por ejemplo, cuando se ejecuta la siguiente línea de comando para escribir algo de memoria en el rango de memoria CXL a través de /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copies, 0.0283507 s, 0.0 kB/s el comando falla como se esperaba. Sin embargo, el código de error es incorrecto. Debería ser "Operación no permitida" en lugar de "Dirección incorrecta". Más grave aún, la comprobación de permisos de /dev/mem en devmem_is_allowed() pasa incorrectamente. Aunque el acceso se impide más tarde porque ioremap() no tiene permiso para mapear la RAM del sistema, es un problema de seguridad potencial. Durante la ejecución del comando, se informa la siguiente advertencia en el registro del núcleo por llamar a ioremap() en la RAM del sistema. ioremap en RAM en 0x0000000490000000 - 0x0000000490000fff ADVERTENCIA: CPU: 2 PID: 416 en arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Rastreo de llamadas: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 Los detalles del proceso de ejecución del comando son los siguientes. En el árbol de recursos anterior, "System RAM" es un descendiente de "CXL Window 0" en lugar de un recurso de nivel superior. Por lo tanto, region_intersects() no informará de forma incorrecta ningún recurso de System RAM en la región de memoria CXL, porque solo comprueba los recursos de nivel superior. En consecuencia, devmem_is_allowed() devolverá 1 (permitirá el acceso a través de /dev/mem) para la región de memoria CXL de forma incorrecta. Afortunadamente, ioremap() no permite mapear System RAM y rechazar el acceso. Por lo tanto, es necesario corregir region_intersects() para que funcione correctamente con el árbol de recursos con "System RAM" no en el nivel superior como se indica anteriormente. Para corregirlo, si encontramos un recurso no coincidente en el nivel superior, continuaremos buscando recursos coincidentes en sus recursos descendientes. Por lo tanto, ya no nos perderemos ningún recurso coincidente en el árbol de recursos. En la nueva implementación, un árbol de recursos de ejemplo |------------- "CXL Window 0" ------------| |-- "System RAM" --| se comportará de manera similar al siguiente árbol de recursos falso para region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "RAM del sistema" --||-- "Ventana CXL 0a" --| Donde "Ventana CXL 0a" es parte de la "Ventana CXL 0" original que no está cubierta por la "RAM del sistema".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: send: corrige la detección de desbordamiento de búfer al copiar la ruta a la entrada de caché A partir de el commit c0247d289e73 ("btrfs: send: annotate struct name_cache_entry with __counted_by()"), anotamos la matriz de longitud variable "name" de la estructura name_cache_entry con __counted_by() para mejorar la detección de desbordamiento. Sin embargo, eso solo no era correcto, porque la longitud de esa matriz no coincide con el campo "name_len" - coincide con eso más 1 para incluir el terminador de cadena NUL, por lo que hace que un kernel fortificado piense que hay un desbordamiento e informe un splat como este: strcpy: desbordamiento de búfer detectado: escritura de 20 bytes de tamaño de búfer 19 ADVERTENCIA: CPU: 3 PID: 3310 en __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs No contaminado 6.11.0-prnet #1 Nombre del hardware: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 15/03/2018 RIP: 0010:__fortify_report+0x45/0x50 Código: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 000000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Seguimiento de llamadas: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent_+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Código: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 000000000000003 R14: 000055c499fab2e0 R15: 000000000000004 Solucione esto al no almacenar el terminador de cadena NUL ya que en realidad no lo necesitamos para las entradas de caché de nombres, de esta manera "name_len" corresponde al tamaño real de la matriz "name". Esto requiere marcar el campo de matriz "nombre" con __nonstring y usar memcpy() en lugar de strcpy() como lo recomiendan las pautas en: https://github.com/KSPP/linux/issues/90