Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige la variable 'mca_funcs' desreferenciada antes de la comprobación NULL en 'amdgpu_mca_smu_get_mca_entry()' Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() advertencia: variable desreferenciada antes de verificar 'mca_funcs' (ver línea 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev- >mca.mca_funcs; 361 recuentos internacionales; 362 363 interruptor (tipo) { 364 caso AMDGPU_MCA_ERROR_TYPE_UE: 365 recuento = mca_funcs->max_ue_count; Aquí se elimina la referencia a mca_funcs. 366 descanso; 367 caso AMDGPU_MCA_ERROR_TYPE_CE: 368 recuento = mca_funcs->max_ce_count; Aquí se elimina la referencia a mca_funcs. 369 descanso; 370 predeterminado: 371 retorno -EINVAL; 372 } 373 374 si (idx >= recuento) 375 retorno -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ ¡Comprobado demasiado tarde!

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_ct: desinfecta el número de protocolo de capa 3 y 4 en expectativas personalizadas - No permitir familias que no sean NFPROTO_{IPV4,IPV6,INET}. - No permitir el protocolo de capa 4 sin puertos, ya que el puerto de destino es un atributo obligatorio para este objeto.

OpenHarmony v3.2.4 y versiones anteriores permiten que un atacante local provoque que las aplicaciones fallen al obtener permiso.

OpenHarmony v4.0.0 y versiones anteriores permiten que un atacante local cause DOS mediante use after free.

OpenHarmony v4.0.0 y versiones anteriores permiten a un atacante local la ejecución de código arbitrario mediante escritura fuera de los límites.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/sched: corrige null-ptr-deref en la entidad init. El error se puede activar enviando un amdgpu_cs_wait_ioctl al controlador DRM AMDGPU en cualquier ASIC con contexto válido. El error fue reportado por Joonkyo Jung . Por ejemplo, el siguiente código: static void Syzkaller2(int fd) { union drm_amdgpu_ctx arg1; unión drm_amdgpu_wait_cs arg2; arg1.in.op = AMDGPU_CTX_OP_ALLOC_CTX; ret = drmIoctl(fd, 0x140106442 /* amdgpu_ctx_ioctl */, &arg1); arg2.in.handle = 0x0; arg2.in.timeout = 0x2000000000000; arg2.in.ip_type = AMD_IP_VPE /* 0x9 */; arg2->in.ip_instance = 0x0; arg2.in.ring = 0x0; arg2.in.ctx_id = arg1.out.alloc.ctx_id; drmIoctl(fd, 0xc0206449 /* AMDGPU_WAIT_CS * /, &arg2); } Se podría suponer que el ioctl AMDGPU_WAIT_CS sin trabajo enviado previamente debe devolver el error, pero la siguiente confirmación 1decbf6bb0b4dc56c9da6c5e57b994ebfc2be3aa modificó la lógica y permitió que sched_rq fuera igual a NULL. Como resultado, cuando no hay trabajo, ioctl AMDGPU_WAIT_CS devuelve éxito. El cambio corrige null-ptr-deref en la entidad init y la siguiente pila demuestra la condición de error: [+0.000007] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000028 [+0.007086] #PF: acceso de lectura del supervisor en modo kernel [+0.005234 ] #PF: error_code(0x0000) - página no presente [ +0.005232] PGD 0 P4D 0 [ +0.002501] Ups: 0000 [#1] PREEMPT SMP KASAN NOPTI [ +0.005034] CPU: 10 PID: 9229 Comm: amd_basic Tainted : GBWL 6.7.0+ #4 [ +0.007797] Nombre del hardware: Nombre del producto del sistema ASUS/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 03/12/2020 [ +0.009798] RIP: 0010:drm_sched_entity_init+0x2d3 /0x420 [gpu_sched] [ +0.006426] Código: 80 00 00 00 00 00 00 00 e8 1a 81 82 e0 49 89 9c 24 c0 00 00 00 4c 89 ef e8 4a 80 82 e0 49 8b 5d 00 48 8 d 7b 28 e8 3d 80 82 e0 <48> 83 7b 28 00 0f 84 28 01 00 00 4d 8d ac 24 98 00 00 00 49 8d 5c [ +0.019094] RSP: 0018:ffffc90014c1fa40 EFLAGS: 00010282 [ +0. 005237] RAX: 0000000000000001 RBX: 0000000000000000 RCX : ffffffff8113f3fa [ +0.007326] RDX: ffffbfff0a7889d RSI: 0000000000000008 RDI: ffffffff853c44e0 [ +0.007264] RBP: ffffc90014c1fa80 R08: 00000000000000 01 R09: ffffbfff0a7889c [ +0.007266] R10: ffffffff853c44e7 R11: 0000000000000001 R12: ffff8881a719b010 [ +0.007263] R13: ffff88810d412748 R14: 0000000000000002 R15: 0000000000000000 [ +0.007264] FS: 00007ffff7045540(0000) GS:ffff8883cc900000(0000) knlGS:0000000000000000 [ +0.00823 6] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.005851] CR2: 0000000000000028 CR3: 000000011912e000 CR4 : 0000000000350ef0 [ +0.007175] Seguimiento de llamadas: [ +0.002561] [ +0.002141] ? show_regs+0x6a/0x80 [+0.003473]? __die+0x25/0x70 [ +0.003124] ? page_fault_oops+0x214/0x720 [+0.004179]? preempt_count_sub+0x18/0xc0 [+0.004093]? __pfx_page_fault_oops+0x10/0x10 [ +0.004590] ? srso_return_thunk+0x5/0x5f [+0.004000]? vprintk_default+0x1d/0x30 [+0.004063]? srso_return_thunk+0x5/0x5f [+0.004087]? vprintk+0x5c/0x90 [ +0.003296] ? drm_sched_entity_init+0x2d3/0x420 [gpu_sched] [+0.005807]? srso_return_thunk+0x5/0x5f [+0.004090]? _printk+0xb3/0xe0 [ +0.003293] ? __pfx__printk+0x10/0x10 [ +0.003735] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [+0.005482]? do_user_addr_fault+0x345/0x770 [ +0.004361] ? exc_page_fault+0x64/0xf0 [+0.003972]? asm_exc_page_fault+0x27/0x30 [+0.004271]? add_taint+0x2a/0xa0 [ +0.003476] ? drm_sched_entity_init+0x2d3/0x420 [gpu_sched] [ +0.005812] amdgpu_ctx_get_entity+0x3f9/0x770 [amdgpu] [ +0.009530] ? terminar_task_switch.isra.0+0x129/0x470 [+0.005068]? __pfx_amdgpu_ctx_get_entity+0x10/0x10 [amdgpu] [ +0.010063] ? __kasan_check_write+0x14/0x20 [ +0.004356] ? srso_return_thunk+0x5/0x5f [+0.004001]? mutex_unlock+0x81/0xd0 [+0.003802]? srso_return_thunk+0x5/0x5f [ +0.004096] amdgpu_cs_wait_ioctl+0xf6/0x270 [amdgpu] [ +0.009355] ? __pfx_ ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bcachefs: toma s_umount solo si se toma una instantánea Cuando estaba probando mongodb sobre bcachefs con compresión, hay una advertencia de lockdep al tomar una instantánea del volumen de datos de mongodb. $ cat test.sh prog=bcachefs $prog subvolumen crear /mnt/data $prog subvolumen crear /mnt/data/snapshots mientras es verdadero;do $prog subvolumen snapshot /mnt/data /mnt/data/snapshots/$(fecha +% s) dormir 1 hecho $ cat /etc/mongodb.conf systemLog: destino: archivo logAppend: verdadera ruta: /mnt/data/mongod.log almacenamiento: dbPath: /mnt/data/ lockdep informes: [3437.452330] ==== ==================================================== [ 3437.452750] ADVERTENCIA: posible dependencia de bloqueo circular detectada [ 3437.453168] 6.7.0-rc7-custom+ #85 Contaminado: GE [ 3437.453562] ---------------------- -------------------------------- [ 3437.453981] bcachefs/35533 está intentando adquirir el bloqueo: [ 3437.454325] ffffa0a02b2b1418 (sb_writers #10){.+.+}-{0:0}, en: filename_create+0x62/0x190 [ 3437.454875] pero la tarea ya mantiene el bloqueo: [ 3437.455268] ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+ }-{3:3}, en: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.456009] cuyo bloqueo ya depende del nuevo bloqueo. [ 3437.456553] la cadena de dependencia existente (en orden inverso) es: [ 3437.457054] -> #3 (&type->s_umount_key#48){.+.+}-{3:3}: [ 3437.457507] down_read+0x3e/0x170 [ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.458206] __x64_sys_ioctl+0x93/0xd0 [ 3437.458498] do_syscall_64+0x42/0xf0 [ 3437.458 779] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 [3437.459155] -> #2 (&c->snapshot_create_lock){+ +++}-{3:3}: [ 3437.459615] down_read+0x3e/0x170 [ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs] [ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs] [ 3437.4 60686] notificar_cambio+0x1f1/0x4a0 [ 3437.461283] do_truncate+0x7f/0xd0 [ 3437.461555] path_openat+0xa57/0xce0 [ 3437.461836] do_filp_open+0xb4/0x160 [ 3437.462116] do_sys_openat2+0x91/0xc0 [ 34 37.462402] __x64_sys_openat+0x53/0xa0 [ 3437.462701] do_syscall_64+0x42/0xf0 [ 3437.462982] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.463359] -> #1 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}: [ 3437.463843] down_write+0x3b/0xc0 [ 3437.464223] bch2_write_it e+0x5b /0xcc0 [bcachefs] [ 3437.464493] vfs_write+0x21b/0x4c0 [ 3437.464653] ksys_write+0x69/0xf0 [ 3437.464839] do_syscall_64+0x42/0xf0 [ 3437.465009] entrada_SYSCALL _64_after_hwframe+0x6e/0x76 [ 3437.465231] -> #0 (sb_writers#10){ .+.+}-{0:0}: [ 3437.465471] __lock_acquire+0x1455/0x21b0 [ 3437.465656] lock_acquire+0xc6/0x2b0 [ 3437.465822] mnt_want_write+0x46/0x1a0 [ 3437.465996] nombre de archivo _create+0x62/0x190 [ 3437.466175] ruta_usuario_create+0x2d /0x50 [ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs] [ 3437.466617] __x64_sys_ioctl+0x93/0xd0 [ 3437.466791] do_syscall_64+0x42/0xf0 [ 3437 .466957] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.467180] otra información que podría ayudarnos a depurar esto: [ 3437.469670] 2 bloqueos mantenidos por bcachefs/35533: otra información que podría ayudarnos a depurar esto: [3437.467507] Existe cadena de: sb_writers#10 --> &c->snapshot_create_lock --> &type->s_umount_key#48 [3437.467979] Posiblemente inseguro escenario de bloqueo: [3437.468223] CPU0 CPU1 [3437.468405] ---- ---- [3437.468585] rlock(&type->s_umount_key#48); [ 3437.468758] bloqueo(&c->snapshot_create_lock); [ 3437.469030] bloqueo(&type->s_umount_key#48); [3437.469291] rlock(sb_writers#10); [ 3437.469434] *** INTERBLOQUEO *** [ 3437.469 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: maneja correctamente los eventos isoc Babble y Buffer Overrun xHCI 4.9 prohíbe explícitamente suponer que xHC ha liberado su propiedad de un TD multi-TRB cuando informa un error en uno de los primeros TRB. Sin embargo, el conductor hace tal suposición y libera el TD, permitiendo que los TRB restantes sean liberados o sobrescritos por nuevos TD. El xHC también debe informar la finalización del TRB final debido a que nosotros establecimos la bandera del COI, independientemente de los errores anteriores. Este evento no se puede reconocer si el TD ya se liberó anteriormente, lo que genera el mensaje de error "Evento de transferencia TRB DMA ptr no forma parte del TD actual". Solucione este problema reutilizando la lógica para procesar errores de transacción isoc. Esto también maneja los hosts que no informan la finalización final. Se corrigió el informe de duración de la transferencia sobre errores de Babble. Pueden deberse a un mal funcionamiento del dispositivo, no hay garantía de que se haya llenado el búfer.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige el error de use-after-free. El error se puede activar enviando un solo amdgpu_gem_userptr_ioctl al controlador DRM AMDGPU en cualquier ASIC con una dirección y tamaño no válidos. El error fue reportado por Joonkyo Jung . Por ejemplo, el siguiente código: static void Syzkaller1(int fd) { struct drm_amdgpu_gem_userptr arg; ret int; arg.addr = 0xffffffffffff0000; arg.tamaño = 0x80000000; /*2 Gb*/ arg.flags = 0x7; ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg); } Debido a que la dirección y el tamaño no son válidos, hay una falla en amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert-> check_shl_overflow, pero incluso en la falla de amdgpu_hmm_register todavía llamamos a amdgpu_hmm_unregister en amdgpu_gem_object_free, lo que provoca el acceso a una dirección incorrecta. La siguiente pila se muestra a continuación cuando el problema se reproduce cuando Kazan está habilitado: [+0.000014] Nombre del hardware: Nombre del producto del sistema ASUS/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 03/12/2020 [+0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340 [ +0.000017] Código: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80 [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246 [ +0.000 013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b [ +0.000011] RDX: dffffc0000000000 RSI: 00000000000000004 RDI: ffff8881a9f78260 [ +0.000010] RBP: ffffc90002 657a70 R08: 0000000000000001 R09: fffff520004caf25 [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00 [ +0.000010] R1 3 : ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260 [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:000000000 0000000 [ +0,000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0,000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0 [+0.000010] Seguimiento de llamadas: [+0.000006] [+0.000007] ? show_regs+0x6a/0x80 [+0.000018]? __advertir+0xa5/0x1b0 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [+0.000018]? report_bug+0x24a/0x290 [+0.000022] ? handle_bug+0x46/0x90 [+0.000015]? exc_invalid_op+0x19/0x50 [+0.000016]? asm_exc_invalid_op+0x1b/0x20 [+0.000017]? kasan_save_stack+0x26/0x50 [+0.000017]? mmu_interval_notifier_remove+0x23b/0x340 [+0.000019]? mmu_interval_notifier_remove+0x327/0x340 [+0.000019]? mmu_interval_notifier_remove+0x23b/0x340 [+0.000020]? __pfx_mmu_interval_notifier_remove+0x10/0x10 [ +0.000017] ? kasan_save_alloc_info+0x1e/0x30 [ +0.000018] ? srso_return_thunk+0x5/0x5f [+0.000014]? __kasan_kmalloc+0xb1/0xc0 [ +0.000018] ? srso_return_thunk+0x5/0x5f [+0.000013]? __kasan_check_read+0x11/0x20 [ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu] [ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu] [ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu] [ +0.004291] ? do_syscall_64+0x5f/0xe0 [+0.000023]? srso_return_thunk+0x5/0x5f [ +0.000017] drm_gem_object_free+0x3b/0x50 [drm] [ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu] [ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004270] ? srso_return_thunk+0x5/0x5f [+0.000014]? __this_cpu_preempt_check+0x13/0x20 [ +0.000015] ? srso_return_thunk+0x5/0x5f [+0.000013]? sysvec_apic_timer_interrupt+0x57/0xc0 [+0.000020]? srso_return_thunk+0x5/0x5f [+0.000014]? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [+0.000022]? drm_ioctl_kernel+0x17b/0x1f0 [drm] [ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm] [ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm] [ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: corrige la advertencia de dependencia de bloqueo con srcu ============================== ========================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.5.0-kfd-yangp #2289 No contaminado ------ ------------------------------------------------ ktrabajador/ 0:2/996 está intentando adquirir el bloqueo: (srcu){.+.+}-{0:0}, en: __synchronize_srcu+0x5/0x1a0 pero la tarea ya mantiene el bloqueo: ((work_completion)(&svms->deferred_list_work )){+.+.}-{0:0}, en: Process_one_work+0x211/0x560 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [ amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+ 0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restaurar_proceso_helper+0x22/0x80 [amdgpu] restaurar_proceso_trabajador+0x2d/0xa0 [amdgpu] proceso_one_work+0x29b/0x560 trabajador_thread+0x3d/0x3d 0 -> #1 ((finalización_trabajo)(&(&proceso- >restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3 a0 mmentrada +0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2 510 lock_sync +0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] Process_one_work+0x29b/0 x560 trabajador_thread+0x3d/0x3d0 otra información que podría ayudarnos a depurar esto : Existe cadena de: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock((work_completion)(&svms- >lista_trabajo_diferido)); bloquear(&info->bloquear#2); lock((work_completion)(&svms->deferred_list_work)); sincronización(srcu);

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: viaje en el tiempo: corrige la corrupción del tiempo En el modo de viaje en el tiempo 'básico' (sin =inf-cpu o =ext), todavía obtenemos interrupciones del temporizador. Esto puede suceder en momentos arbitrarios en el tiempo, es decir, mientras está en timer_read(), lo que adelanta un poco el tiempo. Luego, si recibimos la interrupción después de calcular el nuevo tiempo al que enviar, pero antes de finalizarlo, la interrupción establecerá el tiempo en un valor que es incompatible con el avance, y fallaremos porque el tiempo retrocede cuando hacer el reenvío. Solucione este problema leyendo time_travel_time, calculando el ajuste y realizando el ajuste, todo con las interrupciones desactivadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige la lógica enable_otg_wa [Por qué] Cuando cambiamos a otro modo HDMI, deshabilitamos/habilitamos FIFO innecesariamente, lo que hace que los registros HPO y DIG se configuren al mismo tiempo. momento en el que se supone que sólo se debe configurar HPO. Esto puede provocar que el sistema se cuelgue la próxima vez que cambiemos las frecuencias de actualización, ya que hay casos en los que no deshabilitamos OTG/FIFO pero FIFO está habilitado cuando no debería estarlo. [Cómo] Eliminar completamente la activación/desactivación de FIFO.