Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: corrige otra slab fuera de los límites en fib6_nh_flush_exceptions. Mientras ejecutaba las autopruebas en un kernel habilitado para KASAN, observé una slab fuera de los límites muy similar al informado en la confirmación 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions"). Además, debemos ocuparnos del error de inicialización de fib6_metrics cuando la persona que llama proporciona un nh. La solución es similar: libera explícitamente la ruta en lugar de llamar a fib6_info_release en un objeto medio inicializado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: io_uring: corrige memleak en io_init_wq_offload(). Recibí un informe de pérdida de memoria al realizar la prueba fuzz: BUG: pérdida de memoria objeto sin referencia 0xffff888107310a80 (tamaño 96): comm "syz-executor.6" , pid 4610, sjiffies 4295140240 (edad 20,135 s) volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................. 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<000000001974933b>] kmalloc include/linux/slab.h:591 [en línea] [<000000001974933b>] kzalloc include/linux/slab.h:721 [en línea] [<000000001974933b>] io_init_wq_offload fs/io_uring.c:7920 [en línea] [<000000001974933b>] _context+0x466/0x640 fs/io_uring .c:7955 [<0000000039d0800d>] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016 [<000000008482e78c>] io_uring_add_tctx_node fs/io_uring.c:9052 [en línea] 0000008482e78c>] __do_sys_io_uring_enter fs/io_uring.c:9354 [en línea] [<000000008482e78c>] __se_sys_io_uring_enter fs/io_uring.c:9301 [en línea] [<000000008482e78c>] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301 [<00000000b 875f18f>] do_syscall_x64 arch/x86/entry/common. c:50 [en línea] [<00000000b875f18f>] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 [<000000006b0a8484>] Entry_SYSCALL_64_after_hwframe+0x44/0xae CPU0 CPU1 io_uring_enter io_uring_enter io_uring_add_tctx_node io_uring_add_tctx_node __io_uring_add_tctx_node __io_uring_add_tctx_node io_uring_alloc_task_context io_uring_alloc_task_context io_init_wq_offload io_init_wq_offload hash = kzalloc hash = kzalloc ctx->hash_map = hash ctx->hash_map = hash <- uno de los hash se filtra Al llamar a io_uring_enter() en paralelo, se filtrará el 'hash_map', agregue uring_lock para proteger 'hash_map'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_skbmod: omitir paquetes que no sean Ethernet. Actualmente, tcf_skbmod_act() asume que los paquetes usan Ethernet como protocolo L2, lo cual no siempre es el caso. Como ejemplo, para dispositivos CAN: $ ip link add dev vcan0 type vcan $ ip link set up vcan0 $ tc qdisc add dev vcan0 root handle 1: htb $ tc filter add dev vcan0 parent 1: protocolo ip prio 10 \ matchall action skbmod swap mac Hacer lo anterior corrompe silenciosamente todos los paquetes. No realice acciones de skbmod para paquetes que no sean Ethernet.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netrom: Disminuir el recuento de sock cuando caducan los temporizadores de sock. La confirmación 63346650c1a9 ("netrom: cambiar a API de temporizador de sock") cambió para usar la API de temporizador de sock. Reemplaza mod_timer() por sk_reset_timer() y del_timer() por sk_stop_timer(). La función sk_reset_timer() aumentará el recuento del sock si se llama en un temporizador inactivo, por lo tanto, en caso de que el temporizador expire, debemos disminuir el recuento nosotros mismos en el controlador; de lo contrario, el recuento del calcetín se desequilibrará y el sock nunca será liberado.

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.