Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: PPC: corrección de fuga de kvm_arch_vcpu_ioctl vcpu_load. No se llama a vcpu_put si falla la copia del usuario. Esto puede provocar daños y bloqueos del notificador preventivo, entre otros problemas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: corrige el valor uninit en caif_seqpkt_sendmsg. Cuando nr_segs es igual a cero en iovec_from_user, el objeto msg->msg_iter.iov es la memoria de pila uninit en caif_seqpkt_sendmsg que está definida en ___sys_sendmsg. Entonces no podemos simplemente juzgar msg->msg_iter.iov->base directamente. Podemos usar nr_segs para juzgar si msg en caif_seqpkt_sendmsg tiene buffers de datos. ==================================================== === BUG: KMSAN: valor uninit en caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x1c9/0x220 lib/dump_stack.c: 118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 sock_sendmsg_nosec net/so cket.c: 652 [en línea] sock_sendmsg net/socket.c:672 [en línea] ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [en línea] __sys_sendmmsg+0x808/0xc90 80 __compat_sys_sendmmsg net/compat.c:656 [en línea]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf, sockmap: corrige una posible pérdida de memoria en un caso de error poco probable. Si se necesita skb_linearize y falla, podríamos filtrar un mensaje sobre el manejo de errores. Para solucionarlo, asegúrese de liberar el bloque de mensajes antes de devolver el error. Encontrado durante la revisión del código.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xdp, net: corrige use-after-free en bpf_xdp_link_release. El problema ocurre entre dev_get_by_index() y dev_xdp_attach_link(). En este punto, se llama a dev_xdp_uninstall(). Entonces el enlace xdp no se desconectará automáticamente cuando se libere el desarrollador. Pero link->dev ya apunta a dev, cuando se libera el enlace xdp, se seguirá accediendo a dev, pero se ha liberado. dev_get_by_index() | enlace->dev = dev | | rtnl_lock() | unregister_netdevice_many() | dev_xdp_uninstall() | rtnl_unlock() rtnl_lock(); | dev_xdp_attach_link() | rtnl_unlock(); | | netdev_run_todo() // desarrollador liberado bpf_xdp_link_release() | /* accede al desarrollador. | use after free */ | [45.966867] BUG: KASAN: use after free en bpf_xdp_link_release+0x3b8/0x3d0 [45.967619] Lectura del tamaño 8 en la dirección ffff00000f9980c8 por tarea a.out/732 [45.968297] [45.968502] CPU: 1 PID: Comunicaciones 732: un .out No contaminado 5.13.0+ #22 [ 45.969222] Nombre de hardware: linux,dummy-virt (DT) [ 45.969795] Seguimiento de llamadas: [ 45.970106] dump_backtrace+0x0/0x4c8 [ 45.970564] show_stack+0x30/0x40 [ 45.970981 ] dump_stack_lvl +0x120/0x18c [ 45.971470] print_address_description.constprop.0+0x74/0x30c [ 45.972182] kasan_report+0x1e8/0x200 [ 45.972659] __asan_report_load8_noabort+0x2c/0x50 [ 45.97327 3] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.973834] bpf_link_free+0xd0/0x188 [ 45.974315 ] bpf_link_put+0x1d0/0x218 [ 45.974790] bpf_link_release+0x3c/0x58 [ 45.975291] __fput+0x20c/0x7e8 [ 45.975706] ____fput+0x24/0x30 [ 45.976117] 104/0x258 [ 45.976609] do_notify_resume+0x894/0xaf8 [ 45.977121] work_pending +0xc/0x328 [ 45.977575] [ 45.977775] La dirección del error pertenece a la página: [ 45.978369] página:fffffc00003e6600 refcount:0 mapcount:0 mapeo:00000000000000000 index:0x0 pfn:0x4f998 [ 45.97952 2] banderas: 0x7fffe0000000000(nodo=0| zona=0|lastcpupid=0x3ffff) [ 45.980349] raw: 07fffe0000000000 ffffc00003e6708 ffff0000dac3c010 0000000000000000 [ 45.981309] raw: 0000000000000000 000000000000000 00000000ffffffff 0000000000000000 [ 45.982259] página volcada porque: kasan: mal acceso detectado [ 45.982948] [ 45.983153] Estado de la memoria alrededor de la dirección con errores : [ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.985533] >ffff00000f998080:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.986419] ^ [ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988006] f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988895] ===================================== ============================== [ 45.989773] Deshabilitar la depuración de bloqueo debido a corrupción del kernel [ 45.990552] Pánico del kernel - no sincronizar: panic_on_warn establecido... [ 45.991166] CPU: 1 PID: 732 Comm: a.out Contaminado: GB 5.13.0+ #22 [ 45.991929] Nombre de hardware: linux,dummy-virt (DT) [ 45.992448] Seguimiento de llamadas: [ 45.992753] dump_backtrace+0x0/0x4c8 [ 45.993208] show_stack+0x30/0x40 [ 45.993627] dump_stack_lvl+0x120/0x18c [ 45.994113] dump_stack+0x1c/0x34 [ 45.994530 panic+0x3a4/0x7d 8 [ 45.994930] end_report+0x194/0x198 [ 45.995380] kasan_report+ 0x134/0x200 [ 45.995850] __asan_report_load8_noabort+0x2c/0x50 [ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.997007] bpf_link_free+0xd0/0x188 [ 45.99747 4] bpf_link_put+0x1d0/0x218 [ 45.997942] bpf_link_release+0x3c/0x58 [ 45.998429] __fput+0x20c/ 0x7e8 [ 45.998833] ____fput+0x24/0x30 [ 45.999247] task_work_run+0x104/0x258 [ 45.999731] do_notify_resume+0x894/0xaf8 [ 46.000236] work_pending ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige el rechazo de tail_call_reachable para el intérprete cuando falla jit. Durante las pruebas de f263a81451c1 ("bpf: rastrea correctamente los descriptores de inserción del subprog y corrige el use after free") bajo varias condiciones de fallo, por Por ejemplo, cuando jit_subprogs() falla e intenta limpiar el programa que se ejecutará bajo el intérprete, nos encontramos con el siguiente congelamiento: [...] #127/8 tailcall_bpf2bpf_3:FAIL [...] [ 92.041251] ERROR: KASAN: slab fuera de los límites en ___bpf_prog_run+0x1b9d/0x2e20 [92.042408] Lectura de tamaño 8 en la dirección ffff88800da67f68 por tarea test_progs/682 [92.043707] [92.044030] CPU: 1 PID: 682 Comm: _progs Contaminado: GO 5.13. 0-53301-ge6c08cb33a30-dirty #87 [92.045542] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 01/04/2014 [92.046785] Seguimiento de llamadas: [92.047171] ? __bpf_prog_run_args64+0xc0/0xc0 [92.047773]? __bpf_prog_run_args32+0x8b/0xb0 [92.048389]? __bpf_prog_run_args64+0xc0/0xc0 [92.049019]? ktime_get+0x117/0x130 [...] // ¿unos cientos de líneas [similares] más [92.659025]? ktime_get+0x117/0x130 [92.659845]? __bpf_prog_run_args64+0xc0/0xc0 [92.660738]? __bpf_prog_run_args32+0x8b/0xb0 [92.661528]? __bpf_prog_run_args64+0xc0/0xc0 [92.662378]? print_usage_bug+0x50/0x50 [92.663221]? print_usage_bug+0x50/0x50 [92.664077]? bpf_ksym_find+0x9c/0xe0 [92.664887]? ktime_get+0x117/0x130 [92.665624]? kernel_text_address+0xf5/0x100 [92.666529]? __kernel_text_address+0xe/0x30 [ 92.667725] ? unwind_get_return_address+0x2f/0x50 [92.668854]? ___bpf_prog_run+0x15d4/0x2e20 [ 92.670185] ? ktime_get+0x117/0x130 [92.671130]? __bpf_prog_run_args64+0xc0/0xc0 [92.672020]? __bpf_prog_run_args32+0x8b/0xb0 [92.672860]? __bpf_prog_run_args64+0xc0/0xc0 [92.675159]? ktime_get+0x117/0x130 [92.677074]? lock_is_held_type+0xd5/0x130 [92.678662]? ___bpf_prog_run+0x15d4/0x2e20 [ 92.680046] ? ktime_get+0x117/0x130 [92.681285]? __bpf_prog_run32+0x6b/0x90 [92.682601]? __bpf_prog_run64+0x90/0x90 [92.683636]? lock_downgrade+0x370/0x370 [92.684647]? mark_held_locks+0x44/0x90 [92.685652]? ktime_get+0x117/0x130 [92.686752]? lockdep_hardirqs_on+0x79/0x100 [92.688004]? ktime_get+0x117/0x130 [92.688573]? __cant_migrate+0x2b/0x80 [ 92.689192] ? bpf_test_run+0x2f4/0x510 [92.689869]? bpf_test_timer_continue+0x1c0/0x1c0 [92.690856]? rcu_read_lock_bh_held+0x90/0x90 [92.691506]? __kasan_slab_alloc+0x61/0x80 [92.692128]? eth_type_trans+0x128/0x240 [92.692737]? __build_skb+0x46/0x50 [92.693252]? bpf_prog_test_run_skb+0x65e/0xc50 [92.693954]? bpf_prog_test_run_raw_tp+0x2d0/0x2d0 [92.694639]? __fget_light+0xa1/0x100 [ 92.695162] ? bpf_prog_inc+0x23/0x30 [92.695685]? __sys_bpf+0xb40/0x2c80 [92.696324]? bpf_link_get_from_fd+0x90/0x90 [92.697150]? mark_held_locks+0x24/0x90 [92.698007]? lockdep_hardirqs_on_prepare+0x124/0x220 [92.699045]? finish_task_switch+0xe6/0x370 [92.700072]? lockdep_hardirqs_on+0x79/0x100 [92.701233]? finish_task_switch+0x11d/0x370 [92.702264]? __switch_to+0x2c0/0x740 [ 92.703148] ? mark_held_locks+0x24/0x90 [92.704155]? __x64_sys_bpf+0x45/0x50 [92.705146]? do_syscall_64+0x35/0x80 [92.706953]? Entry_SYSCALL_64_after_hwframe+0x44/0xae [...] Resulta que el rechazo del programa de e411901c0b77 ("bpf: permitir tailcalls en subprogramas BPF para x64 JIT") tiene errores ya que env->prog->aux->tail_call_reachable nunca es cierto. La confirmación ebf7d1f508a7 ("bpf, x64: reelaboración de pro/epílogo y manejo de tailcall en JIT") agregó un rastreador en check_max_stack_ Depth() que propaga la condición tail_call_reachable a través de los subprogramas. Esta información luego se asigna al ---truncado--- del subprograma.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: corrige el error de use after free durante el reinicio. Limpia el siguiente descriptor a observar (next_to_watch) al limpiar el anillo TX. De lo contrario, se pueden producir accesos a la memoria no válidos. Si igb_poll() se ejecuta mientras se reinicia el controlador, esto puede hacer que el controlador intente liberar un skb que ya estaba liberado. (El fallo es más difícil de reproducir con el controlador igb, pero existe el mismo problema potencial ya que el código es idéntico al de igc)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igc: corrige el error de use after free durante el reinicio. Limpia el siguiente descriptor a observar (next_to_watch) al limpiar el anillo TX. De lo contrario, se pueden producir accesos a la memoria no válidos. Si igc_poll() se ejecuta mientras se reinicia el controlador, esto puede hacer que el controlador intente liberar un skb que ya estaba liberado. Mensaje de registro: [101.525242] refcount_t: desbordamiento insuficiente; use after free. [101.525251] ADVERTENCIA: CPU: 1 PID: 646 AT LIB/REFCOUNT.C: 28 RefCount_warn_saturate+0xab/0xf0 [101.525259] Módulos vinculados en: Sch_etf (E) Sch_Mqprio (E) RFKILL (E) INTEL_RAPL_MSR (E) INTER ) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd (E) cryptd(E) pegamento_helper(E) snd_hda_codec_hdmi(E) rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E) soundwire_generic_allocation(E) ) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E) iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E) soundwire_bus (E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) text4(E ) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) i915(E) ahci(E) libahci(E) ehci_pci(E) igb (E) xhci_pci(E) ehci_hcd(E) [ 101.525303] drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E) e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E) usbcore(E) drm(E) button( E) video(E) [ 101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Contaminado: GE 5.10.30-rt37-tsn1-rt-ipipe #ipipe [ 101.525320] Nombre de hardware: SIEMENS AG SIMATIC IPC427D /A5E31233588, BIOS V17.02.09 31/03/2017 [ 101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0 [ 101.525325] Código: 05 31 48 44 01 01 e8 f0 c6 42 00 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48 44 01 01 e8 d1 c6 42 00 <0f> 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff 48 c7 c7 d0 a8 f3 [ 101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286 [ 101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001 [ 101.525330] RDX: 000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff [ 101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50 [ 101.525333] fffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00 [ 101.525335] R13: ffff98fd6b0b1000 R14: 00000000000000039 R15: ffff98fd6be35c40 [ 101.525337] FS: 0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000 [ 101.525339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0 [ 101.525343] Seguimiento de llamadas: [ 101.525346] sock_wfree+0x9c/0xa0 [ 101.52 5353] unix_destruct_scm+0x7b/0xa0 [ 101.525358] skb_release_head_state+0x40/0x90 [ 101.525362] skb_release_all+0xe/0x30 [ 101.525364] napi_consume_skb+0x57/0x160 [ 101.525367] igc_poll+0xb7/0xc80 [igc] [ 101.525376] ? sched_clock+0x5/0x10 [101.525381]? sched_clock_cpu+0xe/0x100 [ 101.525385] net_rx_action+0x14c/0x410 [ 101.525388] __do_softirq+0xe9/0x2f4 [ 101.525391] __local_bh_enable_ip+0xe3/0x110 [ 5395] ? irq_finalize_oneshot.part.47+0xe0/0xe0 [ 101.525398] irq_forced_thread_fn+0x6a/0x80 [ 101.525401] irq_thread+0xe8/0x180 [ 101.525403] ? wake_threads_waitq+0x30/0x30 [101.525406]? irq_thread_check_affinity+0xd0/0xd0 [ 101.525408] kthread+0x183/0x1a0 [ 101.525412] ? kthread_park+0x80/0x80 [ 101.525415] ret_from_fork+0x22/0x30

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: sched: corrige la pérdida de memoria en tcindex_partial_destroy_work Syzbot informó una pérdida de memoria en tcindex_set_parms(). El problema estaba en el hash perfecto no liberado en tcindex_partial_destroy_work(). En tcindex_set_parms() se asigna un nuevo tcindex_data y algunos campos del anterior se copian al nuevo, pero no el hash perfecto. Dado que tcindex_partial_destroy_work() es la función de destrucción del antiguo tcindex_data, necesitamos liberar un hash perfecto para evitar pérdidas de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kvm: evite ataques basados en especulacion desde accesos a memslot fuera de rango. El mecanismo de KVM para acceder a la memoria del invitado traduce una dirección física del invitado (gpa) a una dirección virtual del host usando el botón derecho. gpa desplazado (también conocido como gfn) y una estructura kvm_memory_slot. La traducción se realiza en __gfn_to_hva_memslot usando la siguiente fórmula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE Se espera que gfn esté dentro de los límites de la memoria física del huésped. Sin embargo, un invitado puede acceder a direcciones físicas no válidas de tal manera que el gfn no sea válido. __gfn_to_hva_memslot se llama desde kvm_vcpu_gfn_to_hva_prot, que primero recupera un memslot a través de __gfn_to_memslot. Si bien __gfn_to_memslot verifica que el gfn esté dentro de los límites de la memoria física del huésped o no, una CPU puede especular el resultado de la verificación y continuar la ejecución de manera especulativa usando un gfn ilegal. La especulación puede resultar en el cálculo de un hva fuera de los límites. Si la dirección virtual del host resultante se utiliza para cargar otra dirección física de invitado, se trata efectivamente de un dispositivo Spectre que consta de dos lecturas consecutivas, la segunda de las cuales depende de los datos de la primera. En este momento no está claro si hay casos en los que esto sea explotable. El autor original de este parche informó un caso interesante que implica visitar tablas de páginas de invitados en x86. En este momento, estos no son vulnerables porque la lectura de hva pasa por get_user(), que contiene una barrera de especulación LFENCE. Sin embargo, hay parches en progreso para x86 uaccess.h para enmascarar las direcciones del kernel en lugar de usar LFENCE; Una vez que aterrizan, un invitado podría usar la especulación para leer desde el espacio de direcciones del anillo 3 del VMM. Otras arquitecturas, como ARM, ya utilizan el método de enmascaramiento de direcciones y serían susceptibles a este mismo tipo de dispositivos de acceso dependientes de datos. Por lo tanto, este parche protege proactivamente contra estos ataques al enmascarar gfns fuera de los límites en __gfn_to_hva_memslot, lo que bloquea la especulación sobre hvas no válidos. Sean Christopherson señaló que este parche no cubre kvm_read_guest_offset_cached. Sin embargo, esto se limita a unos pocos bytes después del final de la caché y, por lo tanto, es poco probable que sea útil en el contexto de la construcción de una cadena de accesos dependientes de datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: pci_generic: corrige posible use after free en mhi_pci_remove(). La ruta de eliminación de este controlador llama a del_timer(). Sin embargo, esa función no espera hasta que finalice el controlador del temporizador. Esto significa que es posible que el controlador del temporizador aún esté ejecutándose después de que haya finalizado la función de eliminación del controlador, lo que daría como resultado un use after free. Para solucionarlo, llame a del_timer_sync(), lo que garantiza que el controlador del temporizador haya finalizado y no pueda reprogramarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: misc: brcmstb-usb-pinmap: verifique el valor de retorno después de llamar a platform_get_resource() Causará un null-ptr-deref si platform_get_resource() devuelve NULL, necesitamos verificar el retorno valor.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: corrige la lectura de use after free en drm_getunique(). Hay un error de tiempo de verificación a tiempo de uso en drm_getunique() debido a la recuperación de file_priv. ->master antes de bloquear el mutex maestro del dispositivo. Se puede ver un ejemplo en el informe de fallo del error de use after free encontrado por Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 En el informe, el puntero maestro se utilizó después de ser liberado. Esto se debe a que otro proceso adquirió el mutex maestro del dispositivo en drm_setmaster_ioctl() y luego sobrescribió fpriv->master en drm_new_set_master(). El antiguo valor de fpriv->master se liberó posteriormente antes de que se desbloqueara el mutex. Para solucionar este problema, bloqueamos el mutex maestro del dispositivo antes de recuperar el puntero desde fpriv->master. Este parche pasa la prueba del reproductor Syzbot.