Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: ref-verify: corrige use-after-free después de una acción de referencia no válida En btrfs_ref_tree_mod() después de que insertamos exitosamente la nueva entrada de referencia (variable local 'ref') en el rbtree de la entrada de bloque respectiva (variable local 'be'), si encontramos una acción inesperada de BTRFS_DROP_DELAYED_REF, generamos un error y liberamos la entrada de referencia sin eliminarla del rbtree de la entrada de bloque. Luego, en la ruta de error de btrfs_ref_tree_mod(), llamamos a btrfs_free_ref_cache(), que itera sobre todas las entradas de bloque y luego llama a free_block_entry() para cada una, y allí activaremos un use-after-free cuando se nos llame contra la entrada de bloque a la que agregamos la entrada de referencia liberada a su rbtree, ya que el rbtree todavía apunta a la entrada de bloque, ya que no la eliminamos del rbtree antes de liberarla en la ruta de error en btrfs_ref_tree_mod(). Solucione esto eliminando la nueva entrada de referencia del rbtree antes de liberarla. Syzbot informa esto con los siguientes seguimientos de pila: Error BTRFS (estado EA del bucle0 del dispositivo): Ref acción 2, raíz 5, ref_root 0, padre 8564736, propietario 0, desplazamiento 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [en línea] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [en línea] __se_sys_unlinkat fs/namei.c:4569 [en línea] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Error BTRFS (estado del dispositivo loop0 EA): Ref acción 1, raíz 5, ref_root 5, padre 0, propietario 260, desplazamiento 0, núm_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 actualización_ref_para_vaca+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [en línea] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 Error BTRFS (estado del dispositivo loop0 EA): Acción de referencia 2, raíz 5, ref_root 0, padre 8564736, propietario 0, desplazamiento 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 actualización_ref_para_vaca+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_i ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de use-after-free en btrfs_encoded_read_endio() Shinichiro informó el siguiente use-after-free que a veces sucede en nuestro sistema CI cuando se ejecuta btrfs/284 de fstests en un dispositivo ejecutor de TCMU: ERROR: KASAN: slab-use-after-free en lock_release+0x708/0x780 Lectura de tamaño 8 en la dirección ffff888106a83f18 por la tarea kworker/u80:6/219 CPU: 8 UID: 0 PID: 219 Comm: kworker/u80:6 No contaminado 6.12.0-rc6-kts+ #15 Nombre del hardware: Supermicro Super Server/X11SPi-TF, BIOS 3.3 21/02/2020 Cola de trabajo: btrfs-endio btrfs_end_bio_work [btrfs] Seguimiento de llamadas: dump_stack_lvl+0x6e/0xa0 ? lock_release+0x708/0x780 print_report+0x174/0x505 ? lock_release+0x708/0x780 ? __virt_addr_valid+0x224/0x410 ? lock_release+0x708/0x780 kasan_report+0xda/0x1b0 ? lock_release+0x708/0x780 ? __wake_up+0x44/0x60 lock_release+0x708/0x780 ? __pfx_lock_release+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? bloqueo_se_retiene_tipo+0x9a/0x110 _raw_spin_unlock_irqrestore+0x1f/0x60 __wake_up+0x44/0x60 btrfs_encoded_read_endio+0x14b/0x190 [btrfs] btrfs_check_read_bio+0x8d9/0x1360 [btrfs] ? bloqueo_liberación+0x1b0/0x780 ? trace_lock_acquire+0x12f/0x1a0 ? __pfx_btrfs_check_read_bio+0x10/0x10 [btrfs] ? proceso_una_obra+0x7e3/0x1460 ? bloqueo_adquirir+0x31/0xc0 ? proceso_uno_trabajo+0x7e3/0x1460 proceso_uno_trabajo+0x85c/0x1460 ? __pfx_proceso_uno_trabajo+0x10/0x10 ? asignar_trabajo+0x16c/0x240 subproceso_trabajador+0x5e6/0xfc0 ? __pfx_subproceso_trabajador+0x10/0x10 kthread+0x2c3/0x3a0 ? __pfx_kthread+0x10/0x10 retirar_de_bifurcación+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Asignado por la tarea 3661: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_encoded_read_regular_fill_pages+0x16c/0x6d0 [btrfs] send_extent_data+0xf0f/0x24a0 [btrfs] process_extent+0x48a/0x1830 [btrfs] changed_cb+0x178b/0x2ea0 [btrfs] btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs] _btrfs_ioctl_send+0x117/0x330 [btrfs] btrfs_ioctl+0x184a/0x60a0 [btrfs] __x64_sys_ioctl+0x12e/0x1a0 do_syscall_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 3661: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x4f/0x70 kfree+0x143/0x490 btrfs_encoded_read_regular_fill_pages+0x531/0x6d0 [btrfs] enviar_datos_de_extensión+0xf0f/0x24a0 [btrfs] procesar_extensión+0x48a/0x1830 [btrfs] cambiar_cb+0x178b/0x2ea0 [btrfs] btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs] _btrfs_ioctl_send+0x117/0x330 [btrfs] btrfs_ioctl+0x184a/0x60a0 [btrfs] __x64_sys_ioctl+0x12e/0x1a0 hacer_llamada_al_sistema_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e La dirección con errores pertenece al objeto en ffff888106a83f00 que pertenece a la caché kmalloc-rnd-07-96 de tamaño 96 La dirección con errores se encuentra 24 bytes dentro de la región liberada de 96 bytes [ffff888106a83f00, ffff888106a83f60) La dirección con errores pertenece a la página física: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888106a83800 pfn:0x106a83 flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) page_type: f5(slab) raw: 0017ffffc0000000 ffff888100053680 ffffea0004917200 0000000000000004 sin procesar: ffff888106a83800 0000000080200019 00000001f5000000 0000000000000000 página volcada porque: kasan: se detectó un acceso incorrecto Estado de la memoria alrededor de la dirección con errores: ffff888106a83e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888106a83e80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc >ffff888106a83f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888106a83f80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888106a84000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Fix sleeping in atomic context for PREEMPT_RT el commit bab1c299f3945ffe79 ("LoongArch: Fix sleeping in atomic context in setup_tlb_handler()") cambia el indicador gfp de GFP_KERNEL a GFP_ATOMIC para alloc_pages_node(). Sin embargo, para los núcleos PREEMPT_RT aún podemos obtener un error de "durmiendo en contexto atómico": [ 0.372259] ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 [ 0.372266] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 [ 0.372268] preempt_count: 1, esperado: 0 [ 0.372270] Profundidad de anidamiento de RCU: 1, esperado: 1 [ 0.372272] 3 bloqueos mantenidos por swapper/1/0: [ 0.372274] #0: 900000000c9f5e60 (&pcp->lock){+.+.}-{3:3}, en: get_page_from_freelist+0x524/0x1c60 [ 0.372294] #1: 90000000087013b8 (rcu_read_lock){....}-{1:3}, en: rt_spin_trylock+0x50/0x140 [ 0.372305] #2: 900000047fffd388 (&zone->lock){+.+.}-{3:3}, en: __rmqueue_pcplist+0x30c/0xea0 [ 0.372314] marca de evento irq: 0 [ 0.372316] hardirqs habilitado por última vez en (0): [<000000000000000>] 0x0 [ 0.372322] hardirqs deshabilitado por última vez en (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372329] softirqs se habilitó por última vez en (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372335] softirqs se deshabilitó por última vez en (0): [<000000000000000>] 0x0 [ 0.372341] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 No contaminado 6.12.0-rc7+ #1891 [ 0.372346] Nombre del hardware: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 21/10/2022 [0.372349] Pila: 0000000000000089 9000000005a0db9c 90000000071519c8 9000000100388000 [ 0.372486] 900000010038b890 00000000000000000 900000010038b898 9000000007e53788 [ 0,372492] 900000000815bcc8 900000000815bcc0 900000010038b700 0000000000000001 [ 0,372498] 000000000000001 4b031894b9d6b725 00000000055ec000 9000000100338fc0 [ 0,372503] 00000000000000c4 000000000000001 00000000000002d 0000000000000003 [ 0,372509] 0000000000000030 0000000000000003 000000000055ec000 0000000000000003 [ 0.372515] 900000000806d000 9000000007e53788 00000000000000b0 0000000000000004 [ 0.372521] 000000000000000 000000000000000 900000000c9f5f10 000000000000000 [ 0.372526] 90000000076f12d8 9000000007e53788 9000000005924778 0000000000000000 [ 0.372532] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.372537] ... [ 0.372540] Seguimiento de llamadas: [ 0.372542] [<9000000005924778>] show_stack+0x38/0x180 [ 0.372548] [<90000000071519c4>] nivel_pila_volcado+0x94/0xe4 [ 0.372555] [<900000000599b880>] __might_resched+0x1a0/0x260 [ 0.372561] [<90000000071675cc>] bloqueo_giro_rt+0x4c/0x140 [ 0.372565] [<9000000005cbb768>] __rmqueue_pcplist+0x308/0xea0 [ 0.372570] [<9000000005cbed84>] obtener_página_de_lista_libre+0x564/0x1c60 [ 0.372575] [<9000000005cc0d98>] __alloc_pages_noprof+0x218/0x1820 [ 0.372580] [<900000000593b36c>] tlb_init+0x1ac/0x298 [ 0.372585] [<9000000005924b74>] por_cpu_trap_init+0x114/0x140 [ 0.372589] [<9000000005921964>] cpu_probe+0x4e4/0xa60 [ 0.372592] [<9000000005934874>] inicio_secundario+0x34/0xc0 [ 0.372599] [<900000000715615c>] smpboot_entry+0x64/0x6c Esto se debe a que en los núcleos PREEMPT_RT los spinlocks normales se reemplazan por spinlocks rt y rt_spin_lock() provocará un estado de suspensión. Solucione este problema deshabilitando por completo la optimización NUMA para los núcleos PREEMPT_RT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: se corrige f2fs_bug_on al desinstalar el sistema de archivos, se llama f2fs_evict_inode. La creación de archivos grandes durante el punto de control se desactiva hasta que se queda sin espacio y luego se elimina, luego se vuelve a montar para habilitar el punto de control nuevamente y luego se desmonta el sistema de archivos, lo que activa f2fs_bug_on como se muestra a continuación: ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount No contaminado 6.11.0-rc7-dirty #360 Oops: código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fs_evict_inode+0x58c/0x610 Rastreo de llamadas: __die_body+0x15/0x60 die+0x33/0x50 do_trap+0x10a/0x120 f2fs_evict_inode+0x58c/0x610 do_error_trap+0x60/0x80 f2fs_evict_inode+0x58c/0x610 exc_invalid_op+0x53/0x60 f2fs_evict_inode+0x58c/0x610 La causa raíz es: crear archivos grandes durante el período del punto de control de deshabilitación da como resultado que no haya suficientes segmentos libres, por lo que al volver a escribir el inodo raíz, fallará en f2fs_enable_checkpoint. Al desmontar el sistema de archivos después de habilitar el punto de control, el inodo raíz está sucio en la función f2fs_evict_inode, lo que activa BUG_ON. Los pasos para reproducir son los siguientes: dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fs_dir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fs_dir umount f2fs_dir Vamos a volver a ensuciar el inodo cuando no haya segmentos libres mientras se deshabilita el punto de control.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: leds: clase: Proteger illumination_show() con led_cdev->led_access mutex Se observa un problema de puntero NULL si desde el Proceso A se agrega el dispositivo hid, lo que da como resultado la adición de una adición led_cdev y luego otra llamada para acceder al atributo led_cdev desde el Proceso B puede resultar en un problema de puntero NULL. Use mutex led_cdev->led_access para proteger el acceso a led->cdev y su atributo dentro de illumination_show() y max_brightness_show() y también actualice el comentario para mutex que debe usarse para proteger los campos del dispositivo de clase led. Proceso A Proceso B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 dispositivo_crear_con_grupos+0x48 dispositivo_crear_grupos_vargs+0xc8 dispositivo_agregar+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 intento_de_activar[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invocar_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brillo_show+0x20/0x4c dualshock4_led_get_brillo+0xc/0x74 [ 3313.874295][ T4013] No se puede gestionar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000060 [ 3313.874301][ T4013] Información de aborto de memoria: [ 3313.874303][ T4013] ESR = 0x0000000096000006 [ 3313.874305][ T4013] EC = 0x25: DABT (EL actual), IL = 32 bits [ 3313.874307][ T4013] SET = 0, FnV = 0 [ 3313.874309][ T4013] EA = 0, S1PTW = 0 [ 3313.874311][ T4013] FSC = 0x06: error de traducción de nivel 2 [ 3313.874313][ T4013] Información de cancelación de datos: [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3313.874320][ T4013] pgtable de usuario: páginas de 4k, VA de 39 bits, pgdp=00000008f2b0a000 .. [ 3313.874332][ T4013] Volcando búfer ftrace: [ 3313.874334][ T4013] (búfer ftrace vacío) .. .. [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74 [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60 [ 3313.874656][ T4013] sp : ffffffc0b910bbd0 .. .. [ 3313.874685][ T4013] Rastreo de llamadas: [ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74 [ 3313.874690][ T4013] brillo_show+0x20/0x4c [ 3313.874692][ T4013] dev_attr_show+0x38/0x74 [ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130 [ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54 [ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec [ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4 [ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8 [ 3313.874711][ T4013] ksys_read+0x78/0xe8 [ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c [ 3313.874718][ T4013] invocar_llamada_al_sistema+0x58/0x114 [ 3313.874721][ T4013] el0_svc_common+0x80/0xe0 [ 3313.874724][ T4013] do_el0_svc+0x1c/0x28 [ 3313.874727][ T4013] el0_svc+0x38/0x68 [ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc [ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/tctx: workaround al problema de error de asignación de xa_store() syzbot activó el siguiente WARN_ON: WARNING: CPU: 0 PID: 16 en io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 que es la comprobación de cordura WARN_ON_ONCE(!xa_empty(&tctx->xa)); en __io_uring_free() cuando una io_uring_task está pasando por su put final. El caso de prueba de syzbot incluye la inyección de fallos de asignación de memoria, y parece que xa_store() puede fallar en una de sus asignaciones de memoria y terminar con ->head siendo distinto de NULL aunque no existan entradas en la matriz x. Hasta que se resuelva este problema, puede solucionarlo intentando iterar las entradas en nuestra matriz x y usar WARN_ON_ONCE() si encuentra alguna.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: uvcvideo: Requerir que las entidades tengan un ID único distinto de cero Según la especificación UVC 1.1+ 3.7.2, las unidades y terminales deben tener un ID único distinto de cero. ``` A cada Unidad y Terminal dentro de la función de video se le asigna un número de identificación único, el ID de Unidad (UID) o el ID de Terminal (TID), contenido en el campo bUnitID o bTerminalID del descriptor. El valor 0x00 está reservado para ID indefinido, ``` Por lo tanto, deniega la asignación de una entidad con ID 0 o un ID que pertenezca a una unidad que ya se haya añadido a la lista de entidades. Esto también evita que algunos reproductores syzkaller activen advertencias debido a una cadena de entidades que se refieren a sí mismos. En un caso particular, una Unidad de Salida está conectada a una Unidad de Entrada, ambas con el mismo ID de 1. Pero al buscar el ID de origen de la Unidad de Salida, se encuentra esa misma entidad en lugar de la entidad de entrada, lo que genera dichas advertencias. En otro caso, una cadena hacia atrás se consideró terminada ya que el ID de origen era 0. Más tarde, se encontró esa entidad, pero sus pads no eran válidos. Aquí hay un seguimiento de pila de muestra para uno de esos casos. [ 20.650953] usb 1-1: nuevo dispositivo USB de alta velocidad número 2 usando dummy_hcd [ 20.830206] usb 1-1: Usando ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: descriptor de cadena 0 error de lectura: -71 [ 21.038893] usb 1-1: Se encontró el dispositivo UVC 0.00 (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: ¡El tipo de entidad para la entidad Output 1 no se inicializó! [ 21.041583] uvcvideo 1-1:0.0: ¡El tipo de entidad para la entidad Entrada 1 no se inicializó! [ 21.042218] ------------[ cortar aquí ]------------ [ 21.042536] ADVERTENCIA: CPU: 0 PID: 9 en drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Módulos vinculados en: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 No contaminado 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Cola de trabajo: usb_hub_wq evento_hub [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Código: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Rastreo de llamadas: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1fd/0x290 [ 21.056413] uvc_probe+0x380e/0x3dc0 [ 21.056676] ? __lock_acquire+0x5aa/0x26e0 [ 21.056946] ? find_held_lock+0x33/0xa0 [ 21.057196] ? kernfs_activate+0x70/0x80 [ 21.057533] ? usb_match_dy ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi/libstub: Liberar puntero correcto en caso de falla cmdline_ptr es un parámetro de salida, que no es asignado por la función en sí, y probablemente apunta a la pila del llamador. cmdline se refiere a la asignación del grupo que se debe liberar al limpiar después de una falla, así que páselo en su lugar a free_pool().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mtk-jpeg: Corregir null-ptr-deref durante la descarga del módulo La cola de trabajo debe destruirse en mtk_jpeg_core.c desde el commit 09aea13ecf6f ("media: mtk-jpeg: refactorizar algunas variables"), de lo contrario, el siguiente seguimiento de llamadas puede activarse fácilmente. [ 677.862514] No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual dfff800000000023 [ 677.863633] KASAN: null-ptr-deref en el rango [0x0000000000000118-0x000000000000011f] ... [ 677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: GO 6.8.12-mtk+gfa1a78e5d24b+ #17 ... [ 677.882838] pc : destroy_workqueue+0x3c/0x770 [ 677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw] [ 677.884314] sp : ffff80008ad974f0 [ 677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070 [ 677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690 [ 677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000 [ 677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0 [ 677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10 [ 677.889361] x14: 00000000f1f1f1f1 x13: 000000000000000 x12: x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9: ffff80000aa43e90 [677.891208] x8: 00008fffeea4d1b4 x7: ffff80008ad97267 x6: 0000000000000001 [677.892131] x5: ffff80008ad97260 x4: ffff7000115b2e4d x3: 0000000000000000 [677.893054] x2: 00000000000000023 x1 : dfff800000000000 x0 : 0000000000000118 [ 677.893977] Rastreo de llamadas: [ 677.894297] destroy_workqueue+0x3c/0x770 [ 677.894826] mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw] [ 677.895677] devm_action_release+0x50/0x90 [ 677.896211] release_nodes+0xe8/0x170 [ 677.896688] devres_release_all+0xf8/0x178 [ 677.897219] device_unbind_cleanup+0x24/0x170 [ 677.897785] device_release_driver_internal+0x35c/0x480 [ 677.898461] device_release_driver+0x20/0x38 ... [ 677.912665] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: platform: allegro-dvt: Se solucionó una posible pérdida de memoria en allocate_buffers_internal(). El búfer en el bucle debe liberarse en la ruta de excepción; de lo contrario, puede haber una pérdida de memoria aquí. Para mitigar esto, libere el búfer cuando falle allegro_alloc_buffer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: ts2020: fix null-ptr-deref in ts2020_probe() KASAN informó un problema de null-ptr-deref al ejecutar el siguiente comando: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd No contaminado 6.12.0-rc2+ #24 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 00000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 000000000000006f0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ... La causa del problema es que al usar sysfs para registrar dinámicamente un Dispositivo i2c, no hay datos de plataforma, pero el proceso de sondeo de ts2020 necesita utilizar datos de plataforma, lo que da como resultado el acceso a un puntero nulo. Resuelva este problema agregando comprobaciones a los datos de plataforma.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: imx-jpeg: garantizar que los proveedores de energía se suspendan antes de desconectarlos. Siempre se solicita a los proveedores de energía que se suspendan de forma asincrónica, dev_pm_domain_detach() requiere que el llamador garantice la sincronización adecuada de esta función con las devoluciones de llamadas de administración de energía. de lo contrario, la desconexión puede provocar un pánico del núcleo, como se muestra a continuación: [ 1457.107934] No se puede gestionar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000040 [ 1457.116777] Información de aborto de memoria: [ 1457.119589] ESR = 0x0000000096000004 [ 1457.123358] EC = 0x25: DABT (EL actual), IL = 32 bits [ 1457.128692] SET = 0, FnV = 0 [ 1457.131764] EA = 0, S1PTW = 0 [ 1457.134920] FSC = 0x04: error de traducción de nivel 0 [ 1457.139812] Información de cancelación de datos: [ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1457.158563] pgtable de usuario: páginas de 4k, VA de 48 bits, pgdp=00000001138b6000 [ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000 [ 1457.171792] Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1457.178045] Módulos vinculados en: v4l2_jpeg wave6_vpu_ctrl(-) [última descarga: mxc_jpeg_encdec] [ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 No contaminado 6.6.36-gd23d64eea511 #66 [ 1457.194112] Nombre del hardware: Placa NXP i.MX95 19X19 (DT) [ 1457.199236] Cola de trabajo: pm pm_runtime_work [ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290 [ 1457.214886] lr : __rpm_callback+0x48/0x1d8 [ 1457.218968] sp : ffff80008250bc50 [ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 00000000000000000 [ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 000000000000f4240 [ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008 [ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffffff [ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674 [ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002 [ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9: ffff80008250bbb0 [ 1457.272138] x8: ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000 [ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000 [ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000 [ 1457.293510] Rastreo de llamadas: [ 1457.295946] genpd_runtime_suspend+0x20/0x290 [ 1457.300296] __rpm_callback+0x48/0x1d8 [ 1457.304038] rpm_callback+0x6c/0x78 [ 1457.307515] rpm_suspend+0x10c/0x570 [ 1457.311077] pm_runtime_work+0xc4/0xc8 [ 1457.314813] process_one_work+0x138/0x248 [ 1457.318816] subproceso_trabajador+0x320/0x438 [ 1457.322552] kthread+0x110/0x114 [ 1457.325767] ret_de_la_bifurcación+0x10/0x20