Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: corregir pánico en ejecución de asignación de memfd_pin_folios Si memfd_pin_folios intenta crear una página hugetlb, pero alguien más ya lo hizo, entonces folio obtiene el valor -EEXIST aquí: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; luego en el siguiente viaje a través del bucle "while start_idx" entramos en pánico aquí: if (folio) { folio_put(folio); Para corregirlo, configure folio en NULL en caso de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/filemap: corrección de la serie de parches de pánico de THP filemap_get_folios_contig "memfd-pin huge page fixes". Corrige varios errores que ocurren al usar memfd_pin_folios con páginas hugetlb y THP. Los errores de hugetlb solo afectan cuando la página aún no tiene errores cuando se llama a memfd_pin_folios. El error de THP afecta cuando el desplazamiento inicial pasado a memfd_pin_folios no está alineado con la página enorme. Consulte los mensajes de confirmación para obtener más detalles. Este parche (de 5): memfd_pin_folios en la memoria respaldada por THP entra en pánico si el desplazamiento de inicio solicitado no está alineado con una página enorme: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 El error ocurre aquí porque xas_load devuelve un folio con el valor 2: filemap_get_folios_contig() para (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM "2" es una entrada hermana de xarray. Lo obtenemos porque memfd_pin_folios no redondea los índices pasados a filemap_get_folios_contig a los límites de páginas enormes para THP, por lo que cargamos desde el medio de un rango de páginas enormes para ver un hermano. (Sí redondea para hugetlbfs, en la prueba is_file_hugepages). Para solucionarlo, si el folio es un hermano, entonces devuelva el siguiente índice como punto de inicio para la siguiente llamada a filemap_get_folios_contig.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: master: svc: Se corrige la vulnerabilidad de use after free en el controlador svc_i3c_master debido a la condición de ejecución En la función svc_i3c_master_probe, &master->hj_work está vinculado con svc_i3c_master_hj_work, &master->ibi_work está vinculado con svc_i3c_master_ibi_work. Y svc_i3c_master_ibi_work puede iniciar hj_work, svc_i3c_master_irq_handler puede iniciar ibi_work. Si eliminamos el módulo que llamará a svc_i3c_master_remove para realizar la limpieza, liberará master->base a través de i3c_master_unregister mientras que el trabajo mencionado anteriormente se utilizará. La secuencia de operaciones que pueden provocar un error de UAF es la siguiente: CPU0 CPU1 | Solucione el problema asegurándose de que el trabajo se cancele antes de continuar con la limpieza en svc_i3c_master_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: se corrige la pérdida de dentry en cachefiles_open_file(). Una pérdida de dentry puede producirse cuando una cookie de búsqueda y un cull son concurrentes: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // obtener dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // Devuelve un error pero no coloca dentry Después de eso, se activará la siguiente ADVERTENCIA cuando se desmonte la carpeta del backend: ===================================================================== ERROR: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} todavía en uso (1) [desmontaje de ext4 sda] ADVERTENCIA: CPU: 4 PID: 359261 en fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount No contaminado 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Rastreo de llamadas: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ==================================================================== Independientemente de si cachefiles_open_file() devuelve verdadero o falso, el recuento de referencias obtenido por lookup_positive_unlocked() en cachefiles_look_up_object() debe liberarse. Por lo tanto, libere ese recuento de referencias en cachefiles_look_up_object() para solucionar el problema anterior y simplificar el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: adp5589-keys - corrección de la desreferencia de puntero NULL Registramos una acción devm para llamar a adp5589_clear_config() y luego pasamos el cliente i2c como argumento para que podamos llamar a i2c_get_clientdata() para obtener nuestro objeto de dispositivo. Sin embargo, i2c_set_clientdata() solo se establece al final de la función de sondeo, lo que significa que obtendremos una desreferencia de puntero NULL en caso de que la función de sondeo falle antes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Corrige una ejecución entre la configuración del socket y la creación del hilo de E/S En rxrpc_open_socket(), configura el socket y luego configura el hilo de E/S que lo manejará. Sin embargo, esto es un problema, ya que hay una brecha entre las dos fases en las que un paquete puede llegar a rxrpc_encap_rcv() desde el paquete UDP, pero fallo al intentar despertar el hilo de E/S aún no creado. Como solución rápida, simplemente haga que rxrpc_encap_rcv() descarte el paquete si aún no hay un hilo de E/S. Una solución mejor, pero más intrusiva, tal vez sería reorganizar las cosas de modo que la creación del socket la realice el hilo de E/S.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/vm: mover xa_alloc para evitar UAF Un usuario malintencionado puede adivinar el siguiente id de la máquina virtual antes de que se complete el ioctl y luego llamar a vm destroy ioctl para activar el UAF, ya que create ioctl sigue haciendo referencia a la misma máquina virtual. Mueva xa_alloc hasta el final para evitar esto. v2: - Rebase (seleccionado de el commit dcfd3971327f3ee92765154baebbaece833d3ca9)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: esperar a los trabajadores de reparación antes de detener el kthread del limpiador durante el desmontaje Durante el desmontaje, en close_ctree(), tenemos los siguientes pasos en este orden: 1) Aparcar el kthread del limpiador - esto no destruye el kthread, básicamente detiene su ejecución (las reactivaciones contra él funcionan pero no hacen nada); 2) Detenemos el kthread del limpiador - esto da como resultado la liberación de la estructura respectiva task_struct; 3) Llamamos a btrfs_stop_all_workers() que espera a que se ejecuten trabajos en todas las colas de trabajo y luego libera las colas de trabajo. Syzbot informó de un caso en el que un trabajador de reparación provocó un bloqueo al realizar una entrada retrasada en su inodo mientras intentaba despertar al limpiador en btrfs_add_delayed_iput(), porque la estructura task_struct del kthread del limpiador ya estaba liberada. Esto puede suceder durante el desmontaje porque no esperamos a que haya ningún trabajador de reparación que aún esté en ejecución antes de llamar a kthread_stop() contra el kthread de limpieza, que se detiene y libera todos sus recursos. Solucione esto esperando a que haya algún trabajador de reparación en close_ctree() antes de llamar a kthread_stop() contra el kthread de limpieza y ejecutarlo en espera de entradas retrasadas. Los seguimientos de pila informados por syzbot fueron los siguientes: ERROR: KASAN: slab-use-after-free en __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Lectura de tamaño 8 en la dirección ffff8880272a8a18 por la tarea kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 No contaminado 6.12.0-rc1-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: btrfs-fixup btrfs_work_helper Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 imprimir_dirección_descripción mm/kasan/report.c:377 [en línea] imprimir_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave incluir/linux/spinlock_api_smp.h:110 [en línea] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 constructor de guardado de irq de clase_sin procesar spinlock include/linux/spinlock.h:551 [en línea] intento_de_activación+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 proceso_un_trabajo kernel/workqueue.c:3229 [en línea] proceso_trabajos_programados+0xa63/0x1850 kernel/workqueue.c:3310 subproceso_trabajador+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Asignado por la tarea 2: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [en línea] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [en línea] slab_post_alloc_hook mm/slub.c:4086 [en línea] slab_alloc_node mm/slub.c:4135 [en línea] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [en línea] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [en línea] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Liberado por la tarea 61: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/k---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vhost/scsi: null-ptr-dereference en vhost_scsi_get_req() Desde el commit 3f8ca2e115e5 ("vhost/scsi: Extraer código de manejo común del manejador de cola de control"), se puede activar un error de desreferencia de puntero nulo cuando el invitado envía una solicitud SCSI AN. En vhost_scsi_ctl_handle_vq(), `vc.target` se asigna con `&v_req.tmf.lun[1]` dentro de un bloque switch-case y luego se pasa a vhost_scsi_get_req() que extrae `vc->req` y `tpg`. Sin embargo, para una solicitud `VIRTIO_SCSI_T_AN_*`, tpg no es necesario, por lo que `vc.target` se establece en NULL en esta rama. Más adelante, en vhost_scsi_get_req(), `vc->target` se desreferencia sin comprobarlo, lo que genera un error de desreferencia de puntero nulo. Este error se puede activar desde el invitado. Cuando se produce este error, el proceso vhost_worker se elimina mientras mantiene `vq->mutex` y el tpg correspondiente permanecerá ocupado indefinidamente. A continuación se muestra el informe de KASAN: Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc No contaminado 6.10.0+ #1 Nombre del hardware: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Código: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 b6 04 4 c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 00000000000000000 RDX: 00000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Seguimiento de llamadas: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ fin del seguimiento 000000000000000 ]--- Agreguemos una comprobación en vhost_scsi_get_req. [se corrigen los espacios en blanco]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/timerlat: corrige una ejecución durante el procesamiento de cpuhp. Se encontró otra excepción: el hilo "timerlat/1" se programó en CPU0 y finalmente provocó la corrupción del temporizador: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Módulos vinculados: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 No contaminado 6.11.0-rc7+ #45 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Seguimiento de llamadas: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? ``` Después de rastrear el evento de programación, se descubrió que la migración del hilo "timerlat/1" se realizó durante la creación del hilo. Un análisis posterior confirmó que esto se debe a que el procesamiento en línea de la CPU para osnoise se implementa a través de trabajadores, que es asincrónico con el procesamiento fuera de línea. Cuando se programó el trabajador para crear un hilo, es posible que la CPU ya se haya eliminado de cpu_online_mask durante el proceso fuera de línea, lo que da como resultado la imposibilidad de seleccionar la CPU correcta: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | Para solucionar esto, omita el procesamiento en línea si la CPU ya está fuera de línea.