Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: rt5645: corrige el punto muerto en rt5645_jack_detect_work() Hay una ruta en rt5645_jack_detect_work(), donde rt5645->jd_mutex queda bloqueado para siempre. Eso puede provocar un punto muerto cuando se llama a rt5645_jack_detect_work() por segunda vez. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lan966x: se solucionó el bloqueo al agregar una interfaz con un retraso. Se produce un bloqueo al agregar una de las interfaces lan966x con un retraso. El problema se puede reproducir así: enlace ip agregar nombre bond0 tipo bond miimon modo 100 balance-xor enlace ip establecer dev eth0 master bond0 La razón es que al agregar una interfaz bajo el retraso pasaría por todos los puertos e intentaría calcular determine qué otros puertos están bajo esa interfaz de retraso. Y el problema es que lan966x puede tener puertos que sean punteros NULL ya que no están sondeados. Entonces, al iterar sobre estos puertos, simplemente fallaría porque son punteros NULL. La solución consiste en comprobar si hay punteros NULL antes de acceder a algo desde los puertos. Como hacemos en otros lugares.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5: DPLL, corrige el posible uso después de la activación del temporizador de trabajo retrasado después de la liberación. Logré alcanzar el siguiente uso después de la advertencia de la liberación gratuita recientemente: [2169.711665] ======== ==================================================== ======== [2169.714009] ERROR: KASAN: slab-use-after-free en __run_timers.part.0+0x179/0x4c0 [2169.716293] Escritura de tamaño 8 en la dirección ffff88812b326a70 mediante task swapper/4/0 [ 2169.719022] CPU: 4 PID: 0 Comm: swapper/4 No contaminado 6.8.0-rc2jiri+ #2 [2169.720974] Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02- prebuilt.qemu.org 01/04/2014 [2169.722457] Seguimiento de llamadas: [2169.722756] [2169.723024] dump_stack_lvl+0x58/0xb0 [2169.723417] print_report+0xc5/0x630 [2169.72 3807] ? __virt_addr_valid+0x126/0x2b0 [ 2169.724268] kasan_report+0xbe/0xf0 [ 2169.724667] ? __run_timers.part.0+0x179/0x4c0 [2169.725116]? __run_timers.part.0+0x179/0x4c0 [2169.725570] __run_timers.part.0+0x179/0x4c0 [2169.726003]? call_timer_fn+0x320/0x320 [2169.726404]? lock_downgrade+0x3a0/0x3a0 [2169.726820]? kvm_clock_get_cycles+0x14/0x20 [2169.727257]? ktime_get+0x92/0x150 [2169.727630]? lapic_next_deadline+0x35/0x60 [ 2169.728069] run_timer_softirq+0x40/0x80 [ 2169.728475] __do_softirq+0x1a1/0x509 [ 2169.728866] irq_exit_rcu+0x95/0xc0 [ 2169.7 29241] sysvec_apic_timer_interrupt+0x6b/0x80 [ 2169.729718] [ 2169.729993] [ 2169.730259] asm_sysvec_apic_timer_interrupt+0x16/0x20 [ 2169.730755] RIP: 0010:default_idle+0x13/0x20 [ 2169.731190] Código: c0 08 00 00 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 72 ff ff ff cc cc cc cc 8b 05 9a 7f 1f 02 85 c0 7e 07 0f 00 2d cf 69 43 00 fb f4 c3 66 66 2e 0f 1f 84 00 00 00 00 00 65 48 8b 04 25 c0 93 04 00 [ 2169.732759 ] RSP: 0018:ffff888100dbfe10 EFLAGS : 00000242 [ 2169.733264] RAX: 00000000000000001 RBX: ffff888100d9c200 RCX: ffffffff8241bd62 [ 2169.733925] RDX: ffffed109a848b15 RSI: 000000000 0000004 RDI: ffffffff8127ac55 [ 2169.734566] RBP: 0000000000000004 R08: 0000000000000000 R09: ffffed109a848b14 [ 2169.735200] R10: ffff8884d4245 8a3 R11: 000000000000ba7e R12: ffffffff83d7d3a0 [2169.735835] R13: 1ffff110201b7fc6 R14: 0000000000000000 R15: ffff888100d9c200 [2169.736478] ? ct_kernel_exit.constprop.0+0xa2/0xc0 [2169.736954]? do_idle+0x285/0x290 [ 2169.737323] default_idle_call+0x63/0x90 [ 2169.737730] do_idle+0x285/0x290 [ 2169.738089] ? arch_cpu_idle_exit+0x30/0x30 [2169.738511]? mark_held_locks+0x1a/0x80 [2169.738917]? lockdep_hardirqs_on_prepare+0x12e/0x200 [ 2169.739417] cpu_startup_entry+0x30/0x40 [ 2169.739825] start_secondary+0x19a/0x1c0 [ 2169.740229] ? set_cpu_sibling_map+0xbd0/0xbd0 [ 2169.740673] second_startup_64_no_verify+0x15d/0x16b [ 2169.741179] [ 2169.741686] Asignado por la tarea 1098: [ 2169.742058] kasan_save_s tachuela+0x1c/0x40 [ 2169.742456] kasan_save_track+0x10/0x30 [ 2169.742852] __kasan_kmalloc+0x83 /0x90 [ 2169.743246] mlx5_dpll_probe+0xf5/0x3c0 [mlx5_dpll] [ 2169.743730] sonda_bus_auxiliar+0x62/0xb0 [ 2169.744148] sonda_real+0x127/0x590 [ 2169.744534] __driver_probe_device+0xd2/0x200 [ 2169.744973] dispositivo_driver_attach+0x6b/0xf0 [ 2169.745402] bind_store+ 0x90/0xe0 [ 2169.745761] kernfs_fop_write_iter+0x1df/0x2a0 [ 2169.746210] vfs_write+0x41f/0x790 [ 2169.746579] ksys_write+0xc7/0x160 [ 2169.746947 ] do_syscall_64+0x6f/0x140 [ 2169.747333] Entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 2169.748049] Liberado por la tarea 1220 : [ 2169.748393] kasan_save_stack+0x1c/0x40 [ 2169.748789] kasan_save_track+0x10/0x30 [ 2169.749188] kasan_save_free_info+0x3b/0x50 [ 2169.749621] veneno_slab_object+0x106 /0x180 [ 2169.750044] __kasan_slab_free+0x14/0x50 [ 2169.750451] kfree+0x118/0x330 [ 2169.750792] mlx5_dpll_remove+0xf5/0x110 [mlx5_dpll] [ 2169.751271] auxiliar_bus_remove+0x2e/0x40 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dpll: soluciona un posible punto muerto durante la operación de volcado de netlink Recientemente, he estado recibiendo la siguiente advertencia de punto muerto durante el volcado de pin de dpll: [52804.637962] =========== =========================================== [52804.638536] ADVERTENCIA: posible circular dependencia de bloqueo detectada [52804.639111] 6.8.0-rc2jiri+ #1 No contaminado [52804.639529] -------------------------------- ---------------------- [52804.640104] python3/2984 está intentando adquirir el bloqueo: [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}- {3:3}, en: netlink_dump+0xb3/0x780 [52804.641417] pero la tarea ya mantiene el bloqueo: [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, en: dpll_lock_dumpit+0x13/0x20 [52804.642747] qué bloqueo ya depende del nuevo bloqueo. [52804.643551] la cadena de dependencia existente (en orden inverso) es: [52804.644259] -> #1 (dpll_lock){+.+.}-{3:3}: [52804.644836] lock_acquire+0x174/0x3e0 [52804.645271] __mutex_lock+ 0x119/0x1150 [52804.645723] dpll_lock_dumpit+0x13/0x20 [52804.646169] genl_start+0x266/0x320 [52804.646578] __netlink_dump_start+0x321/0x450 [52804.647056 ] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.647575] genl_rcv_msg+0x1ed/0x3b0 [52804.648001] netlink_rcv_skb+0xdc/ 0x210 [52804.648440] genl_rcv+0x24/0x40 [52804.648831] netlink_unicast+0x2f1/0x490 [52804.649290] netlink_sendmsg+0x36d/0x660 [52804.649742] __sock_sendmsg +0x73/0xc0 [52804.650165] __sys_sendto+0x184/0x210 [52804.650597] __x64_sys_sendto+0x72/0x80 [ 52804.651045] do_syscall_64+0x6f/0x140 [52804.651474] Entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.652001] -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}: [52804.6 52650] check_prev_add+0x1ae/0x1280 [52804.653107 ] __lock_acquire+0x1ed3/0x29a0 [52804.653559] lock_acquire+0x174/0x3e0 [52804.653984] __mutex_lock+0x119/0x1150 [52804.654423] netlink_dump+0xb3/0x780 [52804.654 845] __netlink_dump_start+0x389/0x450 [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.655842] genl_rcv_msg +0x1ed/0x3b0 [52804.656272] netlink_rcv_skb+0xdc/0x210 [52804.656721] genl_rcv+0x24/0x40 [52804.657119] netlink_unicast+0x2f1/0x490 [52804.657570] netlink_sendm sg+0x36d/0x660 [52804.658022] __sock_sendmsg+0x73/0xc0 [52804.658450] __sys_sendto+0x184 /0x210 [52804.658877] __x64_sys_sendto+0x72/0x80 [52804.659322] do_syscall_64+0x6f/0x140 [52804.659752] Entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.66 0281] otra información que podría ayudarnos a depurar esto: [52804.661077] Posible escenario de bloqueo inseguro: [52804.661671] CPU0 CPU1 [52804.662129] ---- ---- [52804.662577] bloqueo(dpll_lock); [52804.662924] bloqueo (nlk_cb_mutex-GENERIC); [52804.663538] bloqueo(dpll_lock); [52804.664073] bloqueo (nlk_cb_mutex-GENERIC); [52804.664490] El problema es el siguiente: __netlink_dump_start() llama a control->start(cb) con nlk->cb_mutex retenido. En control->start(cb) se toma dpll_lock. Luego, nlk->cb_mutex se libera y se toma nuevamente en netlink_dump(), mientras dpll_lock aún se mantiene. Eso lleva a un punto muerto de ABBA cuando otra CPU corre con la misma operación. Solucione este problema moviendo dpll_lock a la devolución de llamada dumpit(), lo que garantiza el orden correcto de toma de bloqueo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no elimine extend_map para el inodo de espacio libre en el error de escritura Mientras ejecutaba el CI para un cambio no relacionado, encontré el siguiente pánico con generic/648 en btrfs_holes_spacecache. error de aserción: block_start != EXTENT_MAP_HOLE, en fs/btrfs/extent_io.c:1385 ------------[ cortar aquí ]------------ ERROR del kernel en fs /btrfs/extent_io.c:1385! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: cargado Contaminado: GW 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Seguimiento de llamadas: < TAREA> extensión_write_cache_pages+0x2ac/0x8f0 extensión_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_ca che+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813 /0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Esto sucede porque no logramos escribir el espacio libre en caché en una instancia, volvemos e intentamos escribirlo nuevamente. Sin embargo, en el segundo paso, llamamos a btrfs_get_extent() en el inodo para obtener el mapeo de extensión. Debido a que este es un nuevo grupo de bloques, y con el inodo de espacio libre siempre buscamos la raíz de confirmación para evitar un punto muerto con el árbol, no encontramos nada y devolvemos un EXTENT_MAP_HOLE para el rango solicitado. Esto sucede porque la primera vez que intentamos escribir el caché de espacio, encontramos un error y, en caso de error, descartamos la asignación de extensión. Esto es normal para archivos normales, pero el inodo de caché de espacio libre es especial. Siempre esperamos que el mapa de extensión sea correcto. Por lo tanto, la segunda vez terminamos con un mapa de extensión falso. Dado que estamos desaprobando esta función, la forma más sencilla de solucionarlo es simplemente omitir la eliminación del rango del mapa de extensión para este rango fallido. Acorté la prueba usando inyección de error para enfatizar el área y facilitar su reproducción. Con este parche implementado, ya no entraremos en pánico con mi prueba de inyección de errores.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no haga ASSERT() si el subvolumen recién creado ya se leyó [ERROR] Hay un bloqueo del syzbot, provocado por ASSERT() durante la creación del subvolumen: la aserción falló: ! anon_dev, en fs/btrfs/disk-io.c:1319 ------------[ cortar aquí ]------------ ERROR del kernel en fs/btrfs/disk -io.c:1319! código de operación no válido: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __ btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b /0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 Entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [CA USO] Durante create_subvol(), después de insertar el elemento raíz para el subvolumen recién creado , activaríamos btrfs_get_new_fs_root() para obtener el btrfs_root de ese subvolumen. La idea aquí es que hemos preasignado un número de dispositivo anónimo para el subvolumen, por lo que podemos asignarlo al nuevo subvolumen. Pero realmente no hay nada que impida que cosas como backref caminen para leer el nuevo subvolumen. Si eso sucede antes de que llamemos a btrfs_get_new_fs_root(), se leerá el subvolumen y ya se habrá asignado un nuevo número de dispositivo anónimo. En ese caso, activaríamos ASSERT(), ya que realmente esperamos que nadie lea ese subvolumen (al que aún no se puede acceder desde fs). Pero aún es posible realizar cosas como el recorrido de referencia atrás para activar la lectura en el subvolumen. Por lo tanto, nuestra suposición sobre ASSERT() no es correcta en primer lugar. [FIX] Arréglelo eliminando ASSERT() y simplemente libere @anon_dev, restablezcalo a 0 y continúe. Si otra cosa lee el árbol de subvolumen, ya debería tener asignado un nuevo anon_dev, por lo que solo necesitamos liberar el preasignado.

Se descubrió que Puwell Cloud Tech Co, Ltd 360Eyes Pro v3.9.5.16(3090516) transmite información confidencial en texto sin cifrar. Esta vulnerabilidad permite a los atacantes interceptar y acceder a información confidencial, incluidas las credenciales de los usuarios y las solicitudes de cambio de contraseña.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige MST Null Ptr para RV. El cambio intenta corregir el siguiente error específico de la plataforma RV: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000008 PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway No contaminado 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Nombre de hardware: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R1 2ET61W (1.31) 28/07/2022 QEPD : 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Código: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 0 0 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8af b9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 00000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 00000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8a fe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000008 CR3: 000000010ddc6000 CR4: 00000 000003506e0 Llamar Seguimiento: ? __morir+0x23/0x70 ? page_fault_oops+0x171/0x4e0? plist_add+0xbe/0x100? exc_page_fault+0x7c/0x180? asm_exc_page_fault+0x26/0x30? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e915 8e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243 bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0x bc0? _copiar_al_usuario+0x25/0x30? drm_ioctl+0x296/0x4b0? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xcd/0x170 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] __x64_sys_ioctl+0x94/0xd0 do_syscall_ 64+0x60/0x90 ? do_syscall_64+0x6c/0x90 Entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4dad17f76f Código: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c> RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 00000000000000010 RAX: ffffffffffffffda RBX: 000055e255a5590 0 RCX: 00007f4dad17f76f RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09 : 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc R13: 0000000000000000b R14: 000055e255a7fc60 R1 5: 000055e255a01eb0 Módulos vinculados en: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep > typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_ cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas> CR2: 0000000000000008 ---[ final de seguimiento 00000000000000000 ]--- RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x26 0 [drm_display_helper] Código: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 00000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 ---truncado- --

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: magnetómetro: rm3100: agregue verificación de los límites para el valor leído de RM3100_REG_TMRC Recientemente, encontramos una falla del kernel en la función rm3100_common_probe causada por el acceso fuera de los límites de la matriz rm3100_samp_rates (debido al hardware subyacente fallas). Agregue verificación de los límites para evitar el acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/timerlat: mover hrtimer_init a timerlat_fd open() Actualmente, el hrtimer de timerlat se inicializa en la primera lectura de timerlat_fd y se destruye al cerrar(). Funciona, pero causa un error si el programa de usuario abre() y cierra() el archivo sin leerlo. Aquí hay un ejemplo: # echo NO_OSNOISE_WORKLOAD > /sys/kernel/debug/tracing/osnoise/options # echo timerlat > /sys/kernel/debug/tracing/current_tracer # cat < ./timerlat_load.py # !/usr/ bin/env python3 timerlat_fd = open("/sys/kernel/tracing/osnoise/per_cpu/cpu0/timerlat_fd", 'r') timerlat_fd.close(); EOF # ./taskset -c 0 ./timerlat_load.py ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000010 #PF: acceso de lectura del supervisor en modo kernel #PF: código_de error(0x0000) - página no presente PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2673 Comm: python3 No contaminado 6.6.13-200.fc39.x86_64 #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16. 3-1.fc39 01/04/2014 RIP: 0010:hrtimer_active+0xd/0x50 Código: 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 57 30 <8b> 42 10 a8 01 74 09 f3 90 8b 42 10 a8 01 75 f7 80 7f 38 00 75 1d RSP: 0018:ffffb031009b7e10 EF LAGS: 00010286 RAX: 000000000002db00 RBX: ffff9118f786db08 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9117a0e64400 RDI: ffff9118f786db08 RBP: ffff9118f786db80 R08: ffff9117a0ddd42 0 R09: ffff9117804d4f70 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9118f786db08 R13: ffff91178fdd5e20 R14: ffff9117840978c0 R15: 000 0000000000000 FS: 00007f2ffbab1740(0000) GS:ffff9118f7840000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000010 CR3: 00000001b402e000 CR4: 000000000075 0ee0 PKRU: 55555554 Seguimiento de llamadas: ? __morir+0x23/0x70 ? page_fault_oops+0x171/0x4e0? srso_alias_return_thunk+0x5/0x7f? avc_has_extended_perms+0x237/0x520? exc_page_fault+0x7f/0x180? asm_exc_page_fault+0x26/0x30? hrtimer_active+0xd/0x50 hrtimer_cancel+0x15/0x40 timerlat_fd_release+0x48/0xe0 __fput+0xf5/0x290 __x64_sys_close+0x3d/0x80 do_syscall_64+0x60/0x90 ? srso_alias_return_thunk+0x5/0x7f? __x64_sys_ioctl+0x72/0xd0? srso_alias_return_thunk+0x5/0x7f? syscall_exit_to_user_mode+0x2b/0x40? srso_alias_return_thunk+0x5/0x7f? do_syscall_64+0x6c/0x90? srso_alias_return_thunk+0x5/0x7f? exit_to_user_mode_prepare+0x142/0x1f0? srso_alias_return_thunk+0x5/0x7f? syscall_exit_to_user_mode+0x2b/0x40? srso_alias_return_thunk+0x5/0x7f? do_syscall_64+0x6c/0x90 Entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f2ffb321594 Código: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 0 0 90 f3 0f 1e fa 80 3d d5 cd 0d 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 7d RSP: 002b:00007ffe8d8eef18 EFLAGS: 00000202 O IG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 00007f2ffba4e668 RCX: 00007f2ffb321594 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffe8d8eef40 R08: 0000000000000000 R09: 0 000000000000000 R10: 55c926e3167eae79 R11: 0000000000000202 R12: 0000000000000003 R13: 00007ffe8d8ef030 R14: 0000000000000000 R15: 0000 7f2ffba4e668 CR2: 0000000000000010 ---[ end trace 0000000000000000 ]--- Mueva hrtimer_init a timerlat_fd open() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige la doble liberación de bloques debido a extensiones incorrectas. moving_len En ext4_move_extents(), move_len solo se actualiza cuando todos los movimientos se ejecutan exitosamente y solo descarta las preasignaciones de orig_inode y donante_inode cuando se mueve_len no es cero. Cuando el bucle no sale después de mover con éxito algunas extensiones, moving_len no se actualiza y permanece en 0, por lo que no descarta las asignaciones previas. Si las extensiones movidas se superponen con las extensiones preasignadas, las extensiones superpuestas se liberan dos veces en ext4_mb_release_inode_pa() y ext4_process_freed_data() (como se describe en el commit 94d7c16cbbbd ("ext4: corrige la doble liberación de bloques con EXT4_IOC_MOVE_EXT")), y se incrementa bb_free dos veces. Por lo tanto, cuando se ejecuta trim, se activa un error de división cero en mb_update_avg_fragment_size() porque bb_free no es cero y bb_fragments es cero. Por lo tanto, actualice move_len después de cada movimiento de extensión para evitar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: BTLB: soluciona el problema al configurar BTLB al iniciar la CPU. Al usar hotplug y activar una CPU de 32 bits, solicite al firmware la información de BTLB para configurar la estática ( bloque) Entradas TLB. Para eso se necesita acceso de escritura a la estructura estática btlb_info, pero como está marcada como __ro_after_init, el kernel falla por defecto y faltan permisos de escritura. Solucione el problema eliminando la anotación __ro_after_init.