Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390: se corrige la doble liberación de los bloques de control de instrumentación de GS y RI en el fallo de fork() Los punteros para los bloques de control de instrumentación de almacenamiento protegido y tiempo de ejecución se almacenan en el thread_struct de la tarea asociada. Estos punteros se copian inicialmente en fork() mediante arch_dup_task_struct() y luego se borran mediante copy_thread() antes de que fork() regrese. Si fork() falla después del dup de la tarea inicial y antes de copy_thread(), la tarea recién asignada y la memoria thread_struct asociada se liberan mediante free_task() -> arch_release_task_struct(). Esto resulta en una doble liberación de las estructuras de información de almacenamiento protegido y tiempo de ejecución porque los campos en la tarea fallida todavía hacen referencia a la memoria asociada con la tarea de origen. Este problema puede manifestarse como un BUG_ON() en set_freepointer() (con CONFIG_SLAB_FREELIST_HARDENED habilitado) o un error de KASAN (si está habilitado) al ejecutar pruebas de fuzzing de llamadas al sistema de Trinity en s390x. Para evitar este problema, borre los campos de puntero asociados en arch_dup_task_struct() inmediatamente después de copiar la nueva tarea. Tenga en cuenta que el indicador RI permanece borrado en copy_thread() porque reside en la memoria de la pila de subprocesos, donde se copia la información de la pila.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/privcmd: corrección del error de salida de privcmd_ioctl_dm_op(). La salida de error de privcmd_ioctl_dm_op() está llamando a unlock_pages() potencialmente con páginas NULL, lo que lleva a una desreferencia NULL. Además, lock_pages() no comprueba si pin_user_pages_fast() ha sido completamente exitoso, lo que resulta en que potencialmente no se bloqueen todas las páginas en la memoria. Esto podría resultar en fallos esporádicos al usar la memoria relacionada en modo de usuario. Corrija todo esto llamando a unlock_pages() siempre con el número real de páginas ancladas, que será cero en caso de que pages sea NULL, y comprobando que el número de páginas ancladas por pin_user_pages_fast() coincida con el número esperado de páginas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: llamada a __md_stop_writes en md_stop. En el enlace [1], podemos ver que raid1d se ejecutaba incluso después de la ruta raid_dtr -> md_stop -> __md_stop. Primero detengamos la escritura en el destructor para alinearla con el comando md-raid normal y solucionar el problema de KASAN. [1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: storvsc: Eliminar WQ_MEM_RECLAIM de storvsc_error_wq. La cola de trabajo storvsc_error_wq no debe marcarse como WQ_MEM_RECLAIM, ya que no necesita avanzar bajo presión de memoria. Marcar esta cola de trabajo como WQ_MEM_RECLAIM puede causar un bloqueo al vaciar una cola de trabajo que no sea WQ_MEM_RECLAIM. En el estado actual, provoca la siguiente advertencia: [ 14.506347] ------------[ cortar aquí ]------------ [ 14.506354] cola de trabajo: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun se está vaciando !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] ADVERTENCIA: CPU: 0 PID: 8 en <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 No contaminado 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Nombre del hardware: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI versión v4.1 09/05/2022 [ 14.506393] Cola de trabajo: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Seguimiento de llamadas: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ fin de seguimiento 2d9633159fdc6ee7 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: No use tnum_range en la comprobación del rango de matriz para los descriptores de poke Hsin-Wei informó un splat de KASAN activado por su fuzzer de tiempo de ejecución BPF que se basa en un syzkaller personalizado: ERROR: KASAN: slab-out-of-bounds en bpf_int_jit_compile+0x1257/0x13f0 Lectura de tamaño 8 en la dirección ffff888004e90b58 por la tarea syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 No contaminado 5.19.0 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x220/0x220 ? find_held_lock+0x2c/0x110 ? __might_fault+0xd6/0x180 ? lock_downgrade+0x6e0/0x6e0 ? lock_is_held_type+0xa6/0x120 ? __might_fault+0x147/0x180 __sys_bpf+0x137b/0x6070 ? bpf_perf_link_attach+0x530/0x530 ? new_sync_read+0x600/0x600 ? __fget_files+0x255/0x450 ? lock_downgrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksys_write+0x1a8/0x260 __x64_sys_bpf+0x7a/0xc0 ? syscall_enter_from_user_mode+0x21/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f917c4e2c2d El problema aquí es que un rango de tnum_range(0, map->max_entries - 1) tiene una capacidad limitada para representar el rango estrecho concreto con el tnum como el conjunto de estados resultantes de value + mask puede resultar en un superconjunto del rango real deseado, y como tal una comprobación tnum_in(range, reg->var_off) puede dar como resultado verdadero cuando no debería, por ejemplo tnum_range(0, 2) daría como resultado 00XX -> v = 0000, m = 0011 de modo que el conjunto deseado de {0, 1, 2} está representado aquí por un superconjunto menos preciso de {0, 1, 2, 3}. Como el registro es un escalar constante, simplemente use el valor concreto reg->var_off.value para la verificación del índice superior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: loop: Comprobar si hay desbordamiento al configurar loop El espacio de usuario puede configurar un bucle mediante una llamada ioctl, en la que se pasa una configuración de tipo loop_config (consulte el caso de lo_ioctl() en la línea 1550 de drivers/block/loop.c). Esto procede a llamar a loop_configure() que a su vez llama a loop_set_status_from_info() (consulte la línea 1050 de loop.c), pasando &config->info que es de tipo loop_info64*. Esta función luego establece los valores apropiados, como el desplazamiento. loop_device tiene lo_offset de tipo loff_t (consulte la línea 52 de loop.c), que está encadenado por typdef a long long, mientras que loop_info64 tiene lo_offset de tipo __u64 (consulte la línea 56 de include/uapi/linux/loop.h). La función copia directamente el desplazamiento de info al dispositivo como se indica a continuación (véase la línea 980 de loop.c): lo->lo_offset = info->lo_offset; Esto genera un desbordamiento que genera una advertencia en iomap_iter() debido a una llamada a iomap_iter_done() que tiene: WARN_ON_ONCE(iter->iomap.offset > iter->pos); Por lo tanto, se debe verificar si hay un valor negativo durante loop_set_status_from_info(). Informe de error: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mprotect: solo hace referencia a la página pfn de intercambio si coincide el tipo Yu Zhao informó un error después de el commit "mm/swap: Agregar swp_offset_pfn() para obtener PFN de la entrada de intercambio" agregó una verificación en swp_offset_pfn() para el tipo de intercambio [1]: ¡ERROR del kernel en include/linux/swapops.h:117! CPU: 46 PID: 5245 Com: EventManager_De Contaminado: GSOL 6.0.0-dbg-DEV #2 RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0 Código: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6 c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e <0f> 0b 48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48 RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282 RAX: 00000000ffffffe8 RBX: 0c00000000000000 RCX: ffffcd5440000000 RDX: 1ffffffffff7a80a RSI: 0000000000000000 RDI: 0c0000000000042b RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: 0000000000000000 R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738 R13: 000000000000042b R14: 0c0000000000042b R15: 1ffffffffff7a80a FS: 00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000440d035b3180 CR3: 0000002243176004 CR4: 00000000003706e0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: change_pte_range+0x36e/0x880 change_p4d_range+0x2e8/0x670 change_protection_range+0x14e/0x2c0 mprotect_fixup+0x1ee/0x330 do_mprotect_pkey+0x34c/0x440 __x64_sys_mprotect+0x1d/0x30 Se activa porque pfn_swap_entry_to_page() podría invocarse, por ejemplo, en una entrada de intercambio genuina. Para solucionarlo, invoque solo cuando se trate de una entrada de migración de escritura donde se use page*. [1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: evitar la corrupción del mapeo de páginas en hugetlb_mcopy_atomic_pte. En el caso de MCOPY_ATOMIC_CONTINUE con un VMA no compartido, las páginas de la caché de páginas se instalan en los ptes. Sin embargo, se llama a hugepage_add_new_anon_rmap por error porque no son vm_shared. Esto corromperá el mapeo de páginas utilizado por el código de la caché de páginas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86: x86-android-tablets: Reparar la pantalla táctil rota en Chuwi Hi8 con BIOS de Windows El manejo de x86-android-tablets para Chuwi Hi8 solo es necesario con el BIOS de Android y está causando problemas con la versión del BIOS de Windows. Específicamente cuando se intenta registrar la pantalla táctil ya presente, x86_acpi_irq_helper_get() llama a acpi_unregister_gsi(), esto interrumpe el funcionamiento de la pantalla táctil y también conduce a un error: [ 14.248946] ------------[ cortar aquí ]------------ [ 14.248954] remove_proc_entry: eliminando el directorio no vacío 'irq/75', filtrando al menos 'MSSL0001:00' [ 14.248983] ADVERTENCIA: CPU: 3 PID: 440 en fs/proc/generic.c:718 remove_proc_entry ... [ 14.249293] unregister_irq_proc+0xe0/0x100 [ 14.249305] free_desc+0x29/0x70 [ 14.249312] irq_free_descs+0x4b/0x80 [ 14.249320] mp_unmap_irq+0x5c/0x60 [ 14.249329] acpi_unregister_gsi_ioapic+0x2a/0x40 [ 14.249338] x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets] [ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets] Agregue una devolución de llamada de inicio para Chuwi Hi8, que detecta cuando el BIOS de Windows está en uso y sale con -ENODEV en ese caso, solucionando esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: Steam: Impedir la desreferencia de puntero nulo en steam_{recv,send}_report. Es posible que un dispositivo malicioso no envíe un Informe de Características. El controlador HID Steam no prevé esto actualmente y desreferencia el puntero 'struct hid_report' obtenido de los dispositivos HID sin verificar primero su validez. Vamos a corregir esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udmabuf: Establezca la máscara DMA para el dispositivo udmabuf (v2) Si la máscara DMA no se establece explícitamente, se produce la siguiente advertencia cuando el espacio de usuario intenta acceder a dma-buf a través de la CPU, como lo informa syzbot aquí: ADVERTENCIA: CPU: 1 PID: 3595 en kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Módulos vinculados en: CPU: 0 PID: 3595 Comm: syz-executor249 No contaminado 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Código: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 00000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 000000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 v2: No olvide cancelar el registro si falla la configuración de la máscara DMA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: pvrusb2: se corrige una fuga de memoria en pvr_probe. El código de gestión de errores en pvr2_hdw_create olvida anular el registro del dispositivo v4l2. Cuando pvr2_hdw_create regresa a pvr2_context_create, llama a pvr2_context_destroy para destruir el contexto, pero mp->hdw es NULL, lo que provoca que pvr2_hdw_destroy regrese directamente. Para solucionar esto, agregue v4l2_device_unregister para reducir el recuento de referencias de la interfaz USB.