Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panthor: Corrección de UAF en el código de debugfs de panthor_gem_create_with_handle(). Es posible que el objeto ya se haya eliminado después de drm_gem_object_put(). En general, el objeto debería estar completamente construido antes de llamar a drm_gem_handle_create(), excepto que el seguimiento de debugfs utiliza un bloqueo, una lista y un indicador independientes para indicar si el objeto se ha inicializado. Dado que estoy trabajando en todo esto, se simplifica añadiendo el objeto a debugfs solo cuando esté listo, lo que nos permite eliminar ese indicador. panthor_gem_debugfs_bo_rm() ya comprueba si se nos ha añadido a la lista o si se trata de una limpieza de la ruta de error. v2: Corrección de problemas de compilación para !CONFIG_DEBUGFS (Adrián). v3: Añadir salto de línea y eliminar comentario obsoleto (Liviu).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/rockchip: vop2: falla correctamente si falta un plano principal para un puerto de vídeo. Cada ventana de un vop2 es utilizable por un conjunto específico de puertos de vídeo, por lo que al vincular el vop2, revisamos la lista de ventanas disponibles intentando encontrar una designada como plano principal y utilizable por ese puerto específico. Posteriormente, el código quiere usar drm_crtc_init_with_planes con ese plano principal encontrado, pero hasta ahora no se ha comprobado si realmente se encontró un plano principal. Por alguna razón, el vp2 rk3576 no tiene una ventana principal utilizable (si vp0 también está en uso), lo que sacó a la luz el problema y terminó en una desreferencia de puntero nulo más adelante. Como esperamos que exista un plano principal para un puerto de vídeo, agregue una comprobación al final de la iteración de la ventana y falle el sondeo si no se encuentra ninguno.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrección del use-after-free en amdgpu_userq_suspend+0x51a/0x5a0 [ +0.000020] ERROR: KASAN: slab-use-after-free in amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000817] Read of size 8 at addr ffff88812eec8c58 by task amd_pci_unplug/1733 [ +0.000027] CPU: 10 UID: 0 PID: 1733 Comm: amd_pci_unplug Tainted: G W 6.14.0+ #2 [ +0.000009] Tainted: [W]=WARN [ +0.000003] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000004] Call Trace: [ +0.000004] [ +0.000003] dump_stack_lvl+0x76/0xa0 [ +0.000011] print_report+0xce/0x600 [ +0.000009] ? srso_return_thunk+0x5/0x5f [ +0.000006] ? kasan_complete_mode_report_info+0x76/0x200 [ +0.000007] ? kasan_addr_to_slab+0xd/0xb0 [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000707] kasan_report+0xbe/0x110 [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000541] __asan_report_load8_noabort+0x14/0x30 [ +0.000005] amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000535] ? stop_cpsch+0x396/0x600 [amdgpu] [ +0.000556] ? stop_cpsch+0x429/0x600 [amdgpu] [ +0.000536] ? __pfx_amdgpu_userq_suspend+0x10/0x10 [amdgpu] [ +0.000536] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? kgd2kfd_suspend+0x132/0x1d0 [amdgpu] [ +0.000542] amdgpu_device_fini_hw+0x581/0xe90 [amdgpu] [ +0.000485] ? down_write+0xbb/0x140 [ +0.000007] ? __mutex_unlock_slowpath.constprop.0+0x317/0x360 [ +0.000005] ? __pfx_amdgpu_device_fini_hw+0x10/0x10 [amdgpu] [ +0.000482] ? __kasan_check_write+0x14/0x30 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? up_write+0x55/0xb0 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? blocking_notifier_chain_unregister+0x6c/0xc0 [ +0.000008] amdgpu_driver_unload_kms+0x69/0x90 [amdgpu] [ +0.000484] amdgpu_pci_remove+0x93/0x130 [amdgpu] [ +0.000482] pci_device_remove+0xae/0x1e0 [ +0.000008] device_remove+0xc7/0x180 [ +0.000008] device_release_driver_internal+0x3d4/0x5a0 [ +0.000007] device_release_driver+0x12/0x20 [ +0.000004] pci_stop_bus_device+0x104/0x150 [ +0.000006] pci_stop_and_remove_bus_device_locked+0x1b/0x40 [ +0.000005] remove_store+0xd7/0xf0 [ +0.000005] ? __pfx_remove_store+0x10/0x10 [ +0.000006] ? __pfx__copy_from_iter+0x10/0x10 [ +0.000006] ? __pfx_dev_attr_store+0x10/0x10 [ +0.000006] dev_attr_store+0x3f/0x80 [ +0.000006] sysfs_kf_write+0x125/0x1d0 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __kasan_check_write+0x14/0x30 [ +0.000005] kernfs_fop_write_iter+0x2ea/0x490 [ +0.000005] ? rw_verify_area+0x70/0x420 [ +0.000005] ? __pfx_kernfs_fop_write_iter+0x10/0x10 [ +0.000006] vfs_write+0x90d/0xe70 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __pfx_vfs_write+0x10/0x10 [ +0.000004] ? local_clock+0x15/0x30 [ +0.000008] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_slab_free+0x5f/0x80 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? fdget_pos+0x1d3/0x500 [ +0.000007] ksys_write+0x119/0x220 [ +0.000005] ? putname+0x1c/0x30 [ +0.000006] ? __pfx_ksys_write+0x10/0x10 [ +0.000007] __x64_sys_write+0x72/0xc0 [ +0.000006] x64_sys_call+0x18ab/0x26f0 [ +0.000006] do_syscall_64+0x7c/0x170 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __pfx___x64_sys_openat+0x10/0x10 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? fpregs_assert_state_consistent+0x21/0xb0 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? syscall_exit_to_user_mode+0x4e/0x240 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? do_syscall_64+0x88/0x170 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? irqentry_exit+0x43/0x50 [ +0.000004] ? srso_return_thunk+0x5 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7996: Se corrige el posible acceso OOB en mt7996_tx() Se corrige el posible acceso fuera de límite en la rutina mt7996_tx si link_id está configurado en IEEE80211_LINK_UNSPECIFIED

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_sync: corrige la doble liberación en 'hci_discovery_filter_clear()' La función 'hci_discovery_filter_clear()' libera la matriz 'uuids' y luego la establece en NULL. Hay una pequeña posibilidad de la siguiente ejecución: 'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOBLE LIBERACIÓN <-------------------------preempted--------------------------------> uuids = NULL; Para solucionarlo, agreguemos un bloqueo alrededor de la llamada 'kfree()' y la asignación del puntero NULL. De lo contrario, se activa el siguiente backtrace: [ ] ------------[ cortar aquí ]------------ [ ] ¡ERROR del kernel en mm/slub.c:547! [ ] Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]-]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, arm64: Arreglar la inicialización de fp para el límite de excepción En el JIT BPF de ARM64 cuando se configura prog->aux->exception_boundary para un programa BPF, no se llama a find_used_callee_regs() porque para un programa que actúa como límite de excepción, se guardan todos los registros guardados del llamado. find_used_callee_regs() establece `ctx->fp_used = true;` cuando ve que se usa FP en cualquiera de las instrucciones. Para los programas que actúan como límite de excepción, ctx->fp_used permanece falso incluso si el programa usa el puntero de frame y, por lo tanto, FP no está configurado para tales programas en el prólogo. Esto puede hacer que el kernel se bloquee debido a un fallo de página. Corríjalo configurando ctx->fp_used = true para los programas con límite de excepción, ya que fp siempre se guarda en tales programas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: neighbor: Se corrigió null-ptr-deref en neigh_flush_dev(). El robot de pruebas del kernel reportó null-ptr-deref en neigh_flush_dev(). [0] La confirmación citada introdujo una lista de vecinos por netdev y convirtió neigh_flush_dev() para usarla en lugar de la tabla hash global. Un aspecto que pasamos por alto es que neigh_table_clear() llama a neigh_ifdown() con NULL dev. Restablezcamos la iteración de la tabla hash. Tenga en cuenta que el módulo IPv6 ya no se puede descargar, por lo que neigh_table_clear() solo se llama cuando IPv6 no se inicializa, lo cual es improbable. [0]: IPv6: Intento de anular el registro del protocolo permanente 136 IPv6: Intento de anular el registro del protocolo permanente 17 Ups: fallo de protección general, probablemente para la dirección no canónica 0xdffffc00000001a0: 0000 [#1] SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000d00-0x0000000000000d07] CPU: 1 UID: 0 PID: 1 Comm: systemd Contaminado: GT 6.12.0-rc6-01246-gf7f52738637f #1 Contaminado: [T]=RANDSTRUCT Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 RIP: 0010:neigh_flush_dev.llvm.6395807810224103582+0x52/0x570 Código: c1 e8 03 42 8a 04 38 84 c0 0f 85 15 05 00 00 31 c0 41 83 3e 0a 0f 94 c0 48 8d 1c c3 48 81 c3 f8 0c 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 38 00 74 08 48 89 df e8 f7 49 93 fe 4c 8b 3b 4d 85 y siguientes 0f RSP: 0000:ffff88810026f408 EFLAGS: 00010206 RAX: 00000000000001a0 RBX: 00000000000000d00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffc0631640 RBP: ffff88810026f470 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: fffffffc0625250 R14: fffffffc0631640 R15: dffffc0000000000 FS: 00007f575cb83940(0000) GS:ffff8883aee00000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f575db40008 CR3: 00000002bf936000 CR4: 000000000000406f0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: __neigh_ifdown.llvm.6395807810224103582+0x44/0x390 neigh_table_clear+0xb1/0x268 ndisc_cleanup+0x21/0x38 [ipv6] init_module+0x2f5/0x468 [ipv6] do_one_initcall+0x1ba/0x628 do_init_module+0x21a/0x530 load_module+0x2550/0x2ea0 __se_sys_finit_module+0x3d2/0x620 __x64_sys_finit_module+0x76/0x88 x64_sys_call+0x7ff/0xde8 do_syscall_64+0xfb/0x1e8 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f575d6f2719 Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 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 8b 0d b7 06 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007fff82a2a268 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000557827b45310 RCX: 00007f575d6f2719 RDX: 0000000000000000 RSI: 00007f575d584efd RDI: 0000000000000004 RBP: 00007f575d584efd R08: 0000000000000000 R09: 0000557827b47b00 R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000020000 R13: 0000000000000000 R14: 0000557827b470e0 R15: 00007f575dbb4270 Módulos vinculados en: ipv6(+)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Eliminar secpath de skb si no se encuentra el estado xfrm El hardware devuelve un identificador único para el estado xfrm de un paquete descifrado, este estado se busca en un xarray. Sin embargo, el estado podría haberse liberado en el momento de esta búsqueda. Actualmente, si no se encuentra el estado, solo se incrementa un contador. La extensión secpath (sp) en skb no se elimina, lo que hace que sp->len se convierta en 0. Posteriormente, funciones como __xfrm_policy_check() intentan acceder a campos como xfrm_input_state(skb)->xso.type (que desreferencia sp->xvec[sp->len - 1]) sin validar primero sp->len. Esto provoca un fallo al desreferenciar un puntero de estado no válido. Este parche evita el fallo eliminando explícitamente la extensión secpath de skb si no se encuentra el estado xfrm después del descifrado del hardware. Esto garantiza que las funciones posteriores no operen en un secpath de longitud cero. ERROR: no se puede manejar el error de página para la dirección: ffffffff000002c8 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 No contaminado 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NINGUNO Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Código: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 00000000000000002 RDI: 00000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Rechazo de acceso más estrecho a campos de puntero ctx. El siguiente programa BPF, simplificado a partir de una reproducción de syzkaller, genera una advertencia del kernel: r0 = *(u8 *)(r1 + 169); exit; Con el campo de puntero sk en el desplazamiento 168 en __sk_buff. Este acceso se detecta como una lectura más estrecha en bpf_skb_is_valid_access porque no coincide con offsetof(struct __sk_buff, sk). Por lo tanto, se permite y posteriormente procede a bpf_convert_ctx_access. Tenga en cuenta que para el caso "is_narrower_load" en convert_ctx_accesses(), insn->off está alineado, por lo que cnt puede no ser 0 porque coincide con offsetof(struct __sk_buff, sk) en bpf_convert_ctx_access. Sin embargo, el tamaño objetivo permanece en 0 y el verificador genera una advertencia del kernel: error del verificador: error durante la conversión de acceso a ctx(1). Este parche corrige este error para devolver un error correcto de "acceso a bpf_context no válido off=X size=Y" en la instrucción de carga. El mismo problema afecta a varios campos en las estructuras de contexto que permiten acceso restringido. Algunos campos no afectados (para sk_msg, sk_lookup y sockopt) también se modificaron para usar bpf_ctx_range_ptr por consistencia. Tenga en cuenta que este fallo de syzkaller se reportó en el enlace "Cierres" a continuación, que solía referirse a un error diferente, corregido en el commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()"). Debido a que syzbot confundió de alguna manera los dos errores, el nuevo fallo y la reproducción no se reportaron a la lista de correo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_devcd_dump: corrige fuera de los límites mediante dev_coredumpv Actualmente, tanto dev_coredumpv como skb_put_data en hci_devcd_dump usan hdev->dump.head. Sin embargo, dev_coredumpv puede liberar el búfer. De la documentación de dev_coredumpm_timeout, que es utilizada por dev_coredumpv: > Crea un nuevo volcado de memoria del dispositivo para el dispositivo dado. Si aún no se ha leído uno anterior, se descarta el nuevo volcado de memoria. La vida útil de los datos está determinada por el marco de volcado de memoria del dispositivo y cuando ya no se necesitan, se llamará a la función @free para liberar los datos. Si el espacio de usuario aún no ha leído los datos, dev_coredumpv descartará el nuevo búfer, liberando hdev->dump.head. Esto genera un error vmalloc-out-of-bounds cuando skb_put_data intenta acceder a hdev->dump.head. Un informe de fallos de syzbot ilustra esto: ======================================================================= ERROR: KASAN: vmalloc-out-of-bounds in skb_put_data include/linux/skbuff.h:2752 [inline] BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844 CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: hci0 hci_devcd_timeout Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105 skb_put_data include/linux/skbuff.h:2752 [inline] hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping Memory state around the buggy address: ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Para evitar este problema, reordene dev_coredumpv para que se llame después de skb_put_data que no libera los datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evitar bucle infinito en rt6_nlmsg_size(). Durante las pruebas del parche anterior, logré activar un bucle infinito en rt6_nlmsg_size() en el siguiente lugar: list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); }. Esto se debe a que fib6_del_route() y fib6_add_rt2node() usan list_del_rcu(), lo que puede confundir a los lectores de rcu, ya que podrían dejar de ver el encabezado de la lista. Reinicie el bucle si f6i->fib6_nsiblings es cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: corrección de un posible bucle infinito en fib6_info_uses_dev(). fib6_info_uses_dev() parece depender de RCU sin protección explícita. Al igual que la corrección anterior en rt6_nlmsg_size(), debemos asegurarnos de que fib6_del_route() o fib6_add_rt2node() no hayan eliminado el ancla de la lista; de lo contrario, corremos el riesgo de un bucle infinito.