Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir uaf para flush rq mientras se itera etiquetas blk_mq_clear_flush_rq_mapping() no se llama durante la sonda scsi, al verificar blk_queue_init_done(). Sin embargo, QUEUE_FLAG_INIT_DONE se borra en del_gendisk por el commit aec89dc5d421 ("bloque: mantener q_usage_counter en modo atómico después de del_gendisk"), por lo tanto, para discos como scsi, seguir blk_mq_destroy_queue() tampoco borrará el flush rq de tags->rqs[], debido al siguiente uaf que nuestro syzkaller encuentra para v6.6: ===================================================================== ERROR: KASAN: slab-use-after-free en blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261 Lectura de tamaño 4 en la dirección ffff88811c969c20 por la tarea kworker/1:2H/224909 CPU: 1 PID: 224909 Comm: kworker/1:2H No contaminado 6.6.0-ga836a5060850 #32 Cola de trabajo: kblockd blk_mq_timeout_work Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364 print_report+0x3e/0x70 mm/kasan/report.c:475 kasan_report+0xb8/0xf0 mm/kasan/report.c:588 blk_mq_find_and_get_req+0x16e/0x1a0 bloque/blk-mq-tag.c:261 bt_iter bloque/blk-mq-tag.c:288 [en línea] __sbitmap_for_each_set include/linux/sbitmap.h:295 [en línea] sbitmap_for_each_set include/linux/sbitmap.h:316 [en línea] bt_for_each+0x455/0x790 bloque/blk-mq-tag.c:325 blk_mq_queue_tag_busy_iter+0x320/0x740 bloque/blk-mq-tag.c:534 blk_mq_timeout_work+0x1a3/0x7b0 bloque/blk-mq.c:1673 proceso_uno_trabajo+0x7c4/0x1450 kernel/workqueue.c:2631 proceso_trabajos_programados kernel/workqueue.c:2704 [en línea] subproceso_trabajador+0x804/0xe40 kernel/workqueue.c:2785 subproceso_k+0x346/0x450 kernel/kthread.c:388 ret_de_bifurcación+0x4d/0x80 arch/x86/kernel/process.c:147 ret_de_bifurcación_asm+0x1b/0x30 arch/x86/entry/entry_64.S:293 Asignado por la tarea 942: pila_guardada_kasan+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [en línea] __kasan_kmalloc mm/kasan/common.c:383 [en línea] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:380 kasan_kmalloc include/linux/kasan.h:198 [en línea] __do_kmalloc_node mm/slab_common.c:1007 [en línea] __kmalloc_node+0x69/0x170 mm/slab_common.c:1014 kmalloc_node include/linux/slab.h:620 [en línea] kzalloc_node include/linux/slab.h:732 [en línea] blk_alloc_flush_queue+0x144/0x2f0 bloque/blk-flush.c:499 blk_mq_alloc_hctx+0x601/0x940 bloque/blk-mq.c:3788 blk_mq_alloc_and_init_hctx+0x27f/0x330 bloque/blk-mq.c:4261 blk_mq_realloc_hw_ctxs+0x488/0x5e0 bloque/blk-mq.c:4294 blk_mq_init_allocated_queue+0x188/0x860 bloque/blk-mq.c:4350 blk_mq_init_queue_data bloque/blk-mq.c:4166 [en línea] blk_mq_init_queue+0x8d/0x100 block/blk-mq.c:4176 scsi_alloc_sdev+0x843/0xd50 drivers/scsi/scsi_scan.c:335 scsi_probe_and_add_lun+0x77c/0xde0 drivers/scsi/scsi_scan.c:1189 __scsi_scan_target+0x1fc/0x5a0 drivers/scsi/scsi_scan.c:1727 scsi_scan_channel drivers/scsi/scsi_scan.c:1815 [en línea] scsi_scan_channel+0x14b/0x1e0 drivers/scsi/scsi_scan.c:1791 scsi_scan_host_selected+0x2fe/0x400 drivers/scsi/scsi_scan.c:1844 scsi_scan+0x3a0/0x3f0 drivers/scsi/scsi_sysfs.c:151 store_scan+0x2a/0x60 drivers/scsi/scsi_sysfs.c:191 dev_attr_store+0x5c/0x90 drivers/base/core.c:2388 sysfs_kf_write+0x11c/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x3fc/0x610 fs/kernfs/file.c:338 call_write_iter include/linux/fs.h:2083 [en línea] new_sync_write+0x1b4/0x2d0 fs/read_write.c:493 vfs_write+0x76c/0xb00 fs/read_write.c:586 ksys_write+0x127/0x250 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Liberado por la tarea 244687: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 --truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: authentication: Fix use-after-free en ubifs_tnc_end_commit Después de una inserción en TNC, el árbol podría dividirse y hacer que un nodo cambie su `znode->parent`. Una eliminación adicional de otros nodos en el árbol (que también podría liberar los nodos), el `znode->cparent` del nodo mencionado anteriormente aún podría apuntar a un nodo liberado. Este `znode->cparent` puede no actualizarse al hacer que los nodos se comprometan en `ubifs_tnc_start_commit()`. Esto podría desencadenar un use-after-free al acceder a `znode->cparent` en `write_index()` en `ubifs_tnc_end_commit()`. Esto se puede activar ejecutando rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync en un bucle y con `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN luego informa: ERROR: KASAN: use-after-free en ubifs_tnc_end_commit+0xa5c/0x1950 Escritura de tamaño 32 en la dirección ffffff800a3af86c por la tarea ubifs_bgt0_20/153 Rastreo de llamadas: dump_backtrace+0x0/0x340 show_stack+0x18/0x24 dump_stack_lvl+0x9c/0xbc print_address_description.constprop.0+0x74/0x2b0 kasan_report+0x1d8/0x1f0 kasan_check_range+0xf8/0x1a0 memcpy+0x84/0xf4 ubifs_tnc_end_commit+0xa5c/0x1950 Asignado por la tarea 401: kasan_save_stack+0x38/0x70 __kasan_kmalloc+0x8c/0xd0 __kmalloc+0x34c/0x5bc tnc_insert+0x140/0x16a4 ubifs_tnc_add+0x370/0x52c ubifs_jnl_write_data+0x5d8/0x870 do_writepage+0x36c/0x510 ubifs_writepage+0x190/0x4dc __writepage+0x58/0x154 escritura_caché_páginas+0x394/0x830 do_writepages+0x1f0/0x5b0 filemap_fdatawrite_wbc+0x170/0x25c intervalo_de_escritura_y_espera_de_archivo+0x140/0x190 ubifs_fsync+0xe8/0x290 intervalo_de_fsync_vfs+0xc0/0x1e4 do_fsync+0x40/0x90 __arm64_sys_fsync+0x34/0x50 invocar_llamada_al_sistema.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 Liberado por la tarea 403: kasan_save_stack+0x38/0x70 kasan_set_track+0x28/0x40 kasan_set_free_info+0x28/0x4c __kasan_slab_free+0xd4/0x13c kfree+0xc4/0x3a0 tnc_delete+0x3f4/0xe40 ubifs_tnc_remove_range+0x368/0x73c ubifs_tnc_remove_ino+0x29c/0x2e0 ubifs_jnl_delete_inode+0x150/0x260 ubifs_evict_inode+0x1d4/0x2e4 El `memcpy()` ofensivo en `ubifs_copy_hash()` tiene un use-after-free cuando un nodo se convierte en raíz en TNC pero aún tiene un `cparent` para un nodo ya liberado. Más específicamente, considere la siguiente TNC: zroot // zp1 // zn Insertar un nuevo nodo `zn_new` con una clave menor que `zn` activará una división en `tnc_insert()` si `zp1` está lleno: zroot / \ / \ zp1 zp2 / \ / \ zn_new zn `zn->parent` ahora se ha movido a `zp2`, *pero* `zn->cparent` todavía apunta a `zp1`. Ahora, considere una eliminación de todos los nodos _excepto_ `zn`. Justo cuando `tnc_delete()` está a punto de eliminar `zroot` y `zp2`: zroot \ \ zp2 \ \ zn `zroot` y `zp2` se liberan y el árbol colapsa: zn `zn` ahora se convierte en el nuevo `zroot`. `get_znodes_to_commit()` ahora solo encontrará `zn`, el nuevo `zroot`, y `write_index()` verificará su `znode->cparent` que apunta erróneamente al `zp1` ya liberado. Por lo tanto, `ubifs_copy_hash()` se llama erróneamente con `znode->cparent->zbranch[znode->iip].hash` que activa el use-after-free. Solucione esto configurando explícitamente `znode->cparent` en `NULL` en `get_znodes_to_commit()` para el nodo raíz. La búsqueda de los nodos sucios ---truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubi: fastmap: corrige nombres de caché de slab duplicados al adjuntar Desde el commit 4c39529663b9 ("slab: Advertir sobre nombres de caché duplicados cuando DEBUG_VM=y"), se pueden detectar los nombres de caché de slab duplicados y se emite una ADVERTENCIA del kernel. En el proceso de conexión rápida de UBI, alloc_ai() podría invocarse dos veces con el mismo nombre de caché de losa 'ubi_aeb_slab_cache', lo que activará los siguientes mensajes de advertencia: kmem_cache con el nombre 'ubi_aeb_slab_cache' ya existe ADVERTENCIA: CPU: 0 PID: 7519 en mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Módulos vinculados en: ubi(+) nandsim [última descarga: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Rastreo de llamadas: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0 El problema se puede reproducir fácilmente cargando el dispositivo UBI mediante fastmap con CONFIG_DEBUG_VM=y. Arréglelo utilizando diferentes nombres de losa para los invocadores de alloc_ai().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4.0: Se corrige un problema de use-after-free en la función open() asincrónica Yang Erkun informa que cuando dos subprocesos abren archivos al mismo tiempo y se ven obligados a abortar antes de que se vea una respuesta, la llamada a nfs_release_seqid() en nfs4_opendata_free() puede dar como resultado un use-after-free del puntero a la tarea rpc inactiva del otro subproceso. La solución es garantizar que si la llamada RPC se aborta antes de que se complete la llamada a nfs_wait_on_sequence(), entonces debemos llamar a nfs_release_seqid() en nfs4_open_release() antes de que se libere la rpc_task.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: asegúrese de que la entrada de caché esté activa antes de cache_show La función `c_show` se llamó con protección de RCU. Esto solo garantiza que `cp` no se liberará. Por lo tanto, el recuento de referencia para `cp` puede caer a cero, lo que activará una advertencia de use-after-free de refcount cuando se llame a `cache_get`. Para resolver este problema, use `cache_get_rcu` para asegurarse de que `cp` permanezca activo. ------------[ cortar aquí ]------------ refcount_t: adición en 0; use-after-free. ADVERTENCIA: CPU: 7 PID: 822 en lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat No contaminado 6.12.0-rc3+ #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 01/04/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Seguimiento de llamadas: c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 hacer_syscall_64+0x5f/0x170 entrada_SYSCALL_64_después_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipc: se corrige la fuga de memoria si msg_init_ns falla en create_ipc_ns. La asignación de memoria por CPU puede fallar durante create_ipc_ns; sin embargo, este error no se gestiona correctamente, ya que ipc sysctls y mq sysctls no se liberan correctamente. Solucione esto liberando estos dos recursos cuando falle. Aquí está la pila kmemleak cuando percpu falló: objeto sin referencia 0xffff88819de2a600 (tamaño 512): comm "shmem_2nstest", pid 120711, jiffies 4300542254 volcado hexadecimal (primeros 32 bytes): 60 aa 9d 84 ff ff ff ff ff fc 18 48 b2 84 88 ff ff `.........H..... 04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff ........ .V..... backtrace (crc be7cba35): [] __kmalloc_node_track_caller_noprof+0x333/0x420 [] kmemdup_noprof+0x26/0x50 [] configuración_mq_sysctls+0x57/0x1d0 [] copia_ipcs+0x29c/0x3b0 [] creación_nuevos_espacios_de_nombres+0x1d0/0x920 [] copia_espacios_de_nombres+0x2e9/0x3e0 [] proceso_de_copia+0x29f3/0x7ff0 [] clon_de_kernel+0xc0/0x650 [] __do_sys_clone+0xa1/0xe0 [] hacer_llamada_al_sistema_64+0xbf/0x1c0 [] entrada_LLAMADA_AL_SISTEMA_64_después_de_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs/blocklayout: No intente anular el registro de un dispositivo de bloque no válido Desde el commit d869da91cccb ("nfs/blocklayout: Reparar la anulación prematura del registro de una clave PR"), un desmontaje de un NFS con diseño SCSI habilitado pNFS puede anular la referencia de un block_device NULL en: bl_unregister_scsi+0x16/0xe0 [blocklayoutdriver] bl_free_device+0x70/0x80 [blocklayoutdriver] bl_free_deviceid_node+0x12/0x30 [blocklayoutdriver] nfs4_put_deviceid_node+0x60/0xc0 [nfsv4] nfs4_deviceid_purge_client+0x132/0x190 [nfsv4] Esto sucede porque, aunque pudimos crear el nfs4_deviceid_node, la búsqueda del dispositivo no pudo adjuntar el dispositivo de bloque a pnfs_block_dev. Si nunca encontramos un dispositivo de bloque para registrar, podemos evitar este caso con el indicador PNFS_BDEV_REGISTERED. Mueva el desreferenciador detrás de la prueba para el indicador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sunrpc: se corrige un problema de UAF causado por el socket TCP del kernel de sunrpc ERROR: KASAN: slab-use-after-free en tcp_write_timer_handler+0x156/0x3e0 Lectura de tamaño 1 en la dirección ffff888111f322cd por la tarea swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 No contaminado 6.12.0-rc4-dirty #7 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 Rastreo de llamadas: dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 asm_sysvec_apic_timer_interrupt+0x1a/0x20 DESCARGA: 0010:default_idle+0xf/0x20 Código: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 RDX: 0000000000000000 RSI: 00000000000000000 RDI: ffffffff9f00590f RBP: 0000000000000000 R08: 00000000000000001 R09: ffffed102360835d R10: ffff88811b041aeb R11: 00000000000000001 R12: 00000000000000000 R13: fffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 llamada_inactiva_predeterminada+0x6b/0xa0 llamada_inactiva_cpuidle+0x1af/0x1f0 inactividad_real+0xbc/0x130 entrada_inicio_cpu+0x33/0x40 inicio_resto+0x11f/0x210 núcleo_inicio+0x39a/0x420 reserva_inicio_x86_64+0x18/0x30 núcleo_inicio_x86_64+0x97/0xa0 inicio_común_64+0x13e/0x141 Asignado por la tarea 595: pila_guardado_kasan+0x24/0x50 seguimiento_guardado_kasan+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Script de reproducción: mkdir -p /mnt/nfsshare mkdir -p /mnt/nfs/netns_1 mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/nfsshare systemctl restart nfs-server chmod 777 /mnt/nfsshare exportfs -i -o rw,no_root_squash *:/mnt/nfsshare ip netns add netns_1 ip link add name veth_1_peer type veth peer veth_1 ifconfig veth_1_peer 11.11.0.254 up ip link set veth_1 netns netns_1 ip netns exec netns_1 ifconfig veth_1 11.11.0.1 ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP (nota: En mi entorno, una operación DESTROY_CLIENTID siempre se envía inmediatamente, interrumpiendo la conexión tcp de nfs). ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1 ip netns del netns_1 La razón aquí es que el socket tcp en netns_1 (lado nfs) se ha apagado y cerrado (hecho en xs_destroy), pero el mensaje FIN (con ack) se descarta y el lado nfsd sigue enviando mensajes de retransmisión. Como resultado, cuando el sock tcp en netns_1 procesa el mensaje recibido, envía el mensaje (mensaje FIN) en la cola de envío y se restablece el temporizador tcp. Cuando se elimina el espacio de nombres de red, la estructura de red a la que accede la función del controlador del temporizador de tcp causa problemas. Para solucionar este problema, mantengamos netns refcnt para el socket de kernel tcp como se hizo en otros módulos. Este es un truco feo que se puede adaptar fácilmente a kernels anteriores. Seguiremos con una solución adecuada que limpie las interfaces, pero puede que no sea tan fácil adaptarla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: corregir el orden del ajuste de qlen Los cambios en sch->q.qlen en torno a qdisc_tree_reduce_backlog() deben realizarse _antes_ de una llamada a dicha función porque, de lo contrario, puede fallar en notificar a los qdisc principales cuando el secundario está a punto de vaciarse.

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: sh: intc: Fix use-after-free bug in register_intc_controller() en la gestión de errores para esta función, d se libera sin quitarlo nunca de intc_list, lo que provocaría un use-after-free. Para solucionar esto, solo agreguémoslo a la lista después de que todo haya sido exitoso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block, bfq: reparar bfqq uaf en bfq_limit_depth() Establecer un nuevo bfqq asignado a bic o eliminar un bfqq liberado de bic están ambos protegidos por bfqd->lock, sin embargo bfq_limit_depth() está diferenciando bfqq de bic sin el bloqueo, esto puede llevar a UAF si el io_context es compartido por múltiples tareas. Por ejemplo, la prueba bfq con io_uring puede activar el siguiente UAF en v6.6: ====================================================================== ERROR: KASAN: slab-use-after-free en bfqq_group+0x15/0x50 Seguimiento de llamadas: dump_stack_lvl+0x47/0x80 print_address_description.constprop.0+0x66/0x300 print_report+0x3e/0x70 kasan_report+0xb4/0xf0 bfqq_group+0x15/0x50 bfqq_request_over_limit+0x130/0x9a0 bfq_limit_depth+0x1b5/0x480 __blk_mq_alloc_requests+0x2b5/0xa00 blk_mq_get_new_requests+0x11d/0x1d0 blk_mq_submit_bio+0x286/0xb00 send_bio_noacct_nocheck+0x331/0x400 __block_write_full_folio+0x3d0/0x640 writepage_cb+0x3b/0xc0 write_cache_pages+0x254/0x6c0 write_cache_pages+0x254/0x6c0 do_writepages+0x192/0x310 filemap_fdatawrite_wbc+0x95/0xc0 __filemap_fdatawrite_range+0x99/0xd0 Asignado por la tarea 808602: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x83/0x90 kmem_cache_alloc_node+0x1b1/0x6d0 bfq_get_queue+0x138/0xfa0 bfq_get_bfqq_handle_split+0xe3/0x2c0 bfq_init_rq+0x196/0xbb0 bfq_insert_request.isra.0+0xb5/0x480 bfq_insert_requests+0x156/0x180 blk_mq_insert_request+0x15d/0x440 blk_mq_submit_bio+0x8a4/0xb00 send_bio_noacct_nocheck+0x331/0x400 __blkdev_direct_IO_async+0x2dd/0x330 blkdev_write_iter+0x39a/0x450 io_write+0x22a/0x840 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x1b/0x30 Liberado por la tarea 808589: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 __kasan_slab_free+0x126/0x1b0 kmem_cache_free+0x10c/0x750 bfq_put_queue+0x2dd/0x770 __bfq_insert_request.isra.0+0x155/0x7a0 bfq_insert_request.isra.0+0x122/0x480 bfq_insert_requests+0x156/0x180 blk_mq_dispatch_plug_list+0x528/0x7e0 blk_mq_flush_plug_list.part.0+0xe5/0x590 __blk_flush_plug+0x3b/0x90 blk_finish_plug+0x40/0x60 do_writepages+0x19d/0x310 filemap_fdatawrite_wbc+0x95/0xc0 Solucione el problema protegiendo bic_to_bfqq() con bfqd->lock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sh: cpuinfo: Se corrige una advertencia para CONFIG_CPUMASK_OFFSTACK Cuando se seleccionan CONFIG_CPUMASK_OFFSTACK y CONFIG_DEBUG_PER_CPU_MAPS, cpu_max_bits_warn() genera una advertencia de tiempo de ejecución similar a la siguiente cuando se muestra /proc/cpuinfo. Corrija esto utilizando nr_cpu_ids (el límite de tiempo de ejecución) en lugar de NR_CPUS para iterar las CPU. [ 3.052463] ------------[ cortar aquí ]------------ [ 3.059679] ADVERTENCIA: CPU: 3 PID: 1 en include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Módulos vinculados en: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd No contaminado 5.19-rc5+ #1052 [ 3.099465] Pila: 9000000100157b08 9000000000f18530 900000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 90000010021de80 90000000101c890 [ 3.138056] 000000000000000 0000000000000000 0000000000000000 0000000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 000000000000004 900000000ef7430 000000000000000 [ 3.167012] 0000000000000009 0000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Seguimiento de llamadas: [ 3.203941] [<90000000002086d8>] mostrar_pila+0x38/0x14c [ 3.210666] [<9000000000cf846c>] nivel_pila_volcado+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] mostrar_info_cpu+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ fin del seguimiento 8b484262b4b8c24c ]---